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Preface 
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tive  to  assess  the  alignment  of  data  representations  between  representative  Army  C4I  and 
modeling  and  simulation  (M&S)  systems. 
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Army  Topographie  Engineering  Center. 
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Executive  Summary 


Background 

Interoperability  between  Command,  Control, 
Communications,  Computers,  and  Intelligence 
(C4I)  and  Modeling  and  Simulation  (M&S)  sys¬ 
tems  is  one  of  the  greatest  challenges  to  the 
M&S  community  today.  Simulations  are  a  cost- 
effective  component  of  Army  force  training,  and 
provide  testing  environments  for  new  systems. 
Simulations  fill  a  void  created  when  exercises 
are  impractical,  thereby  increasing  warfighter 
preparedness.  But  training  on  C4I  systems  re¬ 
quires  an  interface  between  these  systems  and 
the  simulation  system.  To  use  simulations  with 
C4I  systems,  the  Army  has  been  developing 
point-to-point  software  interfaces.  These  ad  hoc 
interfaces  have  failed  to  yield  insights  into 
C4I/M&S  interoperability.  Lacking  such  in¬ 
sights,  each  software  interface  is  a  largely  inde¬ 
pendent  effort  that  wastefully  re-implements 
portions  of  previous  interfaces. 

In  the  past  10  years,  M&S  and  C4I  standards  and 
development  practices  have  diverged  signifi¬ 
cantly.  The  two  communities  now  use  quite  dif¬ 
ferent  data  models  as  well  as  different  architec¬ 
tures.  M&S  uses  the  High  Level  Architecture 
(HLA).  C4I  uses  the  Defense  Information  Infra¬ 
structure  Common  Operating  Environment  (DII 
COE).  Data  model  compatibility  is  a  fundamen¬ 
tal  issue.  Major  interoperability  problems  arise 
when  there  are  data  exchange  requirements  for 
C4I-M&S  interoperation  that  are  not  supported 
by  one  side  of  the  exchange.  Similarly,  interop¬ 
erability  problems  occur  if  data  representations 
differ  significantly  between  systems,  although 
these  problems  are  not  as  bad  as  those  caused  by 
unsupported  data  exchange  requirements. 

Organizations  should  desire  data  compatibility  to 
the  fullest  extent  possible.  General  solutions  to 
interoperability  problems  have  not  emerged  to 
date,  and  lack  of  data  compatibility  appears  to  be 
a  principal  reason  why.  Beginning  in  1993,  with 
the  third  Army  Tactical  Command  and  Control 
Systems  test,  a  cottage  industry  of  custom,  point- 
to-point  C4I-M&S  interfaces  has  grown  up 
around  the  Army's  family  of  Command  and  Con¬ 


trol  (C2)  systems.  Reuse,  standardization,  and 
interoperability  were  seldom  key  design  criteria, 
so  most  of  these  interfaces  link  a  specific  simula¬ 
tion  to  a  specific  C4I  system  and  typically  handle 
only  a  small  subset  of  the  messages  or  data  the 
“target” — or  stimulated — C4I  system  can  accept 
and/or  the  simulation  can  pass. 

Beginning  in  1999,  the  Institute  for  Defense 
Analyses  (IDA)  began  studying  data  compatibil¬ 
ity  with  an  eye  to  determining  how  to  assess  and 
improve  it.  IDA  published  a  series  of  reports  and 
papers  proposing  a  methodology  for  assessing 
compatibility,  and  studying  it  in  the  context  of 
the  Army  Integrated  Core  Data  Model  and  the 
Army’s  Object  Management  Standards  Category 
(OMSC)  objects,  important  U.S.  Army  models  in 
the  C4I  and  M&S  domains,  respectively.  IDA 
determined  that  little  data  compatibility  existed 
between  these  two  models,  and  also  concluded 
that  the  OMSC  was  unlikely  to  promote  data 
compatibility  with  any  C4I  model.  IDA  therefore 
decided  to  investigate  another  M&S  model. 

Purpose 

This  report  extends  IDA’s  previous  studies  on 
the  issue  of  aligning  data  models  of  Army  C4I 
and  M&S  systems.  It  presents  a  more  complete, 
more  general  methodology  for  determining  com¬ 
patibility  than  has  previously  been  published. 
Organizations  can  use  this  methodology  to  per¬ 
form  their  own  studies  and  thereby  improve  the 
prospect  of  interoperability  between  C4I  and 
M&S  systems  they  develop  or  procure. 

The  real  thrust  of  this  report,  though,  is  a  case 
study  of  compatibility  (or  extent  of  alignment) 
between  prominent  existing  C4I  and  M&S  data 
models.  This  study  identifies  compatibility  (or 
alignment)  problems  that  need  to  be  resolved  in 
order  to  enable  development  of  systems  based  on 
these  standard  C4I  and  M&S  models.  In  addi¬ 
tion,  it  makes  recommendations  on  addressing 
these  problems  in  ways  that  move  C4I  and  M&S 
modeling  closer  to  the  goal  of  common  modeling 
standards. 
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Methodology 

The  study  focuses  on  important,  fomally  sanc¬ 
tioned  data  models  in  the  Army  C4I  and  M&S 
domains.  In  the  C4I  domain,  this  is  NATO’s 
Land  Command-and-Control  Information  Ex¬ 
change  Data  Model  (LC2IEDM).  The  LC2IEDM 
is  a  relational  model,  and  is  NATO’s  proposed 
data  exchange  standard  for  tactical  databases.  In 
the  M&S  domain,  the  Warfighter’s  Simulation 
(WARSIM)  will  provide  simulation  tools  to 
Army  leaders  that  they  can  use  to  create  realistic 
operational  conditions  for  education,  training, 
and  mission  rehearsal  to  meet  Title  X  require¬ 
ments.  WARSIM  is  to  run  as  a  federate  of  the 
Joint  Simulation  System  Federation  Object 
Model  (JSIMS  FOM)  ',  which  is  defined  using 
HLA  templates.  In  this  context,  WARSIM  pub¬ 
lishes  a  set  of  classes  to  which  other  federates 
can  subscribe.  It  is  these  classes  that  form  the 
core  of  the  M&S  domain  analyzed  in  this  study. 

The  study  performed  an  analysis  of  alignment  to 
support  an  assessment  of  the  potential  compati¬ 
bility  and  interoperability  of  systems  based  on 
the  examined  data  standards.  The  report  defines 
suitable  technical  concepts  of  alignment  in  order 
to  enable  quantitative  assessments  of  alignment 
between  these  data  models.  Roughly  speaking, 
these  definitions  declare  that  the  LC2IEDM  and 
the  JSIMS  FOM-published  classes  of  WARSIM 
are  in  alignment  to  the  extent  that  LC2IEDM 
modeling  elements  cover  the  data  requirements 
implicit  in  the  JSIMS  FOM  classes. 

The  study  assigned  each  modeling  element  a 
degree  of  alignment,  the  percentage  of  possible 
coverage.  Ideally,  each  element  in  one  model 
ought  to  have  a  100%  degree  of  alignment  with 
an  element  in  the  other  model,  meaning  that 
these  elements  model  the  same  data,  and  allow¬ 
ing  an  LC2IEDM-based  system  and  a  WARSIM- 
based  system  to  interoperate  with  respect  to  these 
elements.  But,  if  a  WARSIM  element  has  no 
counterpart  in  the  LC2IEDM,  there  is  0%  degree 
of  alignment.  Or  the  degree  of  alignment  may  be 
between  0%  and  100%,  as  when  the  LC2IEDM 
and  WARSIM  model  similar  types  of  data,  but 
they  do  not  match  exactly.  Degrees  of  alignment 
lower  than  100%  may  indicate  a  need  to  modify 
the  models  to  achieve  interoperability  (although 
less-than-perfect  alignment  may  be  acceptable). 


Hence,  it  is  also  known  as  the  Land  Compo¬ 
nent  of  JSIMS. 


The  LC2IEDM  is  a  relational  data  model  ex¬ 
pressed  in  the  Integrated  Computer-Aided  Manu¬ 
facturing  Definition  1  Extended  (IDEFIX) 
model,  whereas  WARSIM  has  an  object-like 
model  in  the  JSIMS  FOM.  In  this  sense,  each 
data  model  typifies  its  domain.  One  challenge  of 
alignment  is  to  compare  and  contrast  these  dif¬ 
ferent  types  of  models,  accounting  for  their  dis¬ 
parate  goals. 

Each  alignment  assessment  is  unidirectional.  It 
focuses  either  on  the  degree  to  which  LC2IEDM 
modeling  elements  cover  data  requirements  im¬ 
plicit  in  WARSIM,  or  the  degree  to  which 
JSIMS  FOM-published  elements  of  WARSIM 
cover  data  requirements  implicit  in  the 
LC2IEDM.  It  does  not  cover  both  simultane¬ 
ously.  Both  perspectives  are  valuable,  however, 
and  IDA  therefore  undertook  two  distinct  as¬ 
sessments  to  cover  both  directions. 

WARSIM  models  terrain  characteristics  using 
the  Terrain  Common  Data  Model  (TCDM).  Be¬ 
cause  terrain  characteristics  play  a  central  role  on 
any  M&S  system,  we  also  assess  the  degree  to 
which  the  TCDM  aligns  with  the  LC2IEDM,  and 
vice-versa.  The  TCDM  is  based  on  features,  and 
IDA  undertook  an  assessment  of  each  attributed 
feature,  identifying  LC2IEDM  entities  and  at¬ 
tributes  that  could  model  those  features.  IDA 
also  assessed  the  degree  to  which  those 
LC2IEDM  entities  that  can  model  terrain  charac¬ 
teristics— GEOGRAPHIC-FEATURE  and  FACIL¬ 
ITY — can  be  modeled  by  TCDM  elements. 

The  LC2IEDM  has  been  developed  as  a  refer¬ 
ence  data  model.  However,  many  developers 
have  requirements  to  interoperate  with  the  Army 
Battle  Command  System  (ABCS)  which  uses  the 
Joint  Common  Database  (JCDB)  Data  Model 
(JDM).  Hence,  IDA  performed  a  separate  as¬ 
sessment  in  which  the  degree  of  alignment  be¬ 
tween  WARSIM  and  the  JDM  was  analyzed. 

Findings 

Tables  ES-1,  ES-2,  ES-3,  and  ES-4  summarize 
the  alignment  assessments  undertaken  for  this 
study.  These  summaries  are  based  on  the  detailed 
analyses  of  alignment  between  individual  entities 
and  classes  provided  in  this  report  and  accompa¬ 
nying  databases. 

Each  table  focuses  on  a  particular  concept  that  is 
central  to  both  M&S  and  C4I  domains.  Each 
table  has  two  sets  of  columns.  The  set  on  the  left 
presents  results  from  WARSIM-to-LC2IEDM 
alignment;  the  set  on  the  right  presents  results 
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from  LC2IEDM-to-WARSIM  alignment.  Rows 
show  important  elements  from  eaeh  area,  and  the 
degree  of  alignment  of  the  element.  The  final 
row  shows  the  overall  degree  of  alignment  for 


the  eoneept.  (Table  ES-3,  whieh  presents  the 
results  of  terrain  assessment,  only  presents  the 
overall  degree  of  alignment,  beeause  of  the  large 
number  of  TCDM  features.) 


Table  ES-1.  Summary  of  Unit  Degree  of  Alignment 


1  WARSIM-to-LC2IEDM  Alignment 

LC2IEDM-to-WARSIM  Alignment  I 

JSIMS 

FOM 

Class 

Degree  of  Alignment 
to  the  LC2DM 

LC2IEDM  Entity 

Degree  of 
Alignment  to 
WARSIM 

org 

84% 

COMBAT-UNIT-TYPE 

56% 

org.land 

54% 

HEADQUARTERS-UNIT-TYPE 

55% 

org. land. unit 

46% 

OBJECT-ITEM 

100% 

OBJECT-ITEM-TYPE 

25% 

OBJECT-TYPE 

50% 

ORGANISATION 

83% 

ORGANISATION-ORGANISATION-ASSOCIATION 

50% 

ORGANISATION-ORGANISATION-TYPE- 

ESTABLISHMENT 

0% 

ORGANISATION-TYPE 

64% 

ORGANISATION-TYPE-ESTABLISHMENT 

0% 

ORGANISATION-TYPE-ESTABLISHMENT- 

ORGANISATION-TYPE-DETAIL 

0% 

SUPPORT-UNIT-TYPE 

59% 

UNIT 

88% 

UNIT-TYPE 

56% 

Overall  Degree  of  Alignment:  61% 


Overall  Degree  of  Alignment:  49% 


Table  ES-2.  Summary  of  Materiel  Concept  Degree  of  Alignment 


1  WARSIM-to-LC2IEDM  Alignment  I 

JSIMS  FOM  Class 

Degree  of 
Alignment  to 
the  LC2IEDM 

abstract 

88% 

abstract.land 

86% 

abstract.land.equipment_type 

57% 

abstract.land. personneljype 

82% 

abstract .  1  an  d .  rotary_wi  ng_ty  pe 

57% 

org 

84% 

org.land 

54% 

org. land. equip_group 

53% 

org. land. supply_cache 

52% 

1  LC2IEDM-to-WARSIM  Alignment  | 

LC2IEDM  Entity 

Degree  of 
Alignment 
to  WARSIM 

CAPABILITY 

23% 

EQUIPMENT-TYPE 

55% 

FIRE-CAPABILITY 

20% 

LAND-MANOEUVRE-CAPABILITY 

22% 

MATERIEL 

57% 

MATERIEL-STATUS 

17% 

MATERIEL-TYPE 

69% 

OBJECT-ITEM 

100% 

OBJECT-ITEM-STATUS 

20% 

OBJECT-ITEM-TYPE 

38% 

OBJECT-TYPE 

50% 

OBJECT-TYPE-CAPABILITY-NORM 

75% 

STORAGE-CAPABILITY 

20% 

SURVEILLANCE-CAPABILITY 

24% 
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1  WARSIM-to-LC2IEDM  Alignment  I 

JSIMS  FOM  Class 

Degree  of 
Alignment  to 
the  LC2IEDM 

1  LC2IEDM-to-WARSIM  Alignment  | 

LC2IEDM  Entity 

Degree  of 
Alignment 
to  WARSIM 

Overall  Degree  of  Alignment:  70% 


Overall  Degree  of  Alignment:  42% 


Table  ES-3.  Summary  of  Terrain  Concept  Degree  of  Alignment 


1  LC2IEDM-to-WARSIM  Alignment  I 

Facility  Degree  of  Alignment: 

59% 

Geographic  Feature  Degree  of  Alignment: 

63% 

WARSIM-to-LC2IEDM  Alignment 

Terrain  Degree  of  Alignment: 

41% 

Table  ES-4.  Summary  of  Conceptual  Degrees  of  Alignment 


1  WARSIM-to-LC2IEDM  Alignment 

Conceptual 

Area 

Degree  of  Alignment 

Unit 

61% 

Equipment 

70% 

Environment 

41% 

Ideally,  these  tables  would  show  100%  align¬ 
ment.  But  analysis  of  these  results  clearly  shows 
that  the  Army  has  a  serious  problem  with  data 
model  alignment  between  the  C4I  and  M&S  do¬ 
mains.  Even  if  next  generation  training  and  test¬ 
ing  simulations  are  built  using  standard  simula¬ 
tion  objects,  developers  will  have  to  craft  inter¬ 
faces  to  transform  data  and,  in  many  cases,  cre¬ 
ate  data  that  is  missing  from  the  other  domain. 
The  impact  for  acquisition  of  systems  is  signifi¬ 
cant.  Millions  of  dollars  will  have  to  be  spent 
after  the  systems  are  developed  to  interface  in¬ 
compatible  models,  and  additional  maintenance 
costs  will  be  incurred  as  systems  behind  the  in¬ 
terfaces  change.  These  costs  are  avoidable  to  the 
extent  that  we  can  improve  the  degree  of  align¬ 
ment  of  data  prior  to  implementation. 

Recommendations 

The  recommendations  from  this  study  are  in  two 
classes:  recommendations  for  LC2IEDM  en¬ 
hancements,  and  M&S  recommendations. 

The  recommendations  for  LC2IEDM  enhance¬ 
ments  are  not  specific  to  WARSIM,  but  rather 
support  requirements  from  simulation  systems. 
The  study  found  that  the  structure  of  the 
LC2IEDM  is  generally  suited  to  M&S  data,  but 
the  LC2IEDM’s  coded  values  are  not  broad 
enough  to  support  M&S  needs.  Moreover,  the 


1  LC2IEDM-to-WARSIM  Alignment  | 

Conceptual  Area 

Degree  of  Alignment 

Unit 

49% 

Equipment 

42% 

Environment: 

Facility 

59% 

Geographic-F  eature 

63% 

LC2IEDM’s  environment  model  lacks  both  the 
breadth  and  depth  necessary  for  simulations. 

The  study  found  that  the  JSIMS  FOM-published 
classes  of  WARSIM  have  substantial  limitations 
in  being  able  to  represent  C4I  information.  Army 
M&S  systems  can  benefit  from  a  reference  ob¬ 
ject  model  that  identifies  all  relevant  C4I  data 
elements  within  the  context  of  a  structure  appli¬ 
cable  to  M&S  design.  Development  of  such  a 
model  is  underway  as  a  natural  next  step. 
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1.  Introduction 


Historically,  Command,  Control,  Communications,  Computers,  and  Intelligence  (C4I) 
and  Modeling  and  Simulation  (M&S)  have  been  represented  in  the  serviees  by  separate 
eommunities  with  separate  backgrounds.  C4I  comes  from  the  Command  and  Control 
(C2)  discipline,  which  is  much  older  than  M&S.  C2  has  a  long  history  that  predates  eom- 
puters,  and  so  has  not  always  been  strongly  influenced  by  the  absolute  need  for  unam¬ 
biguousness  that  is  fundamental  to  a  computer-based  implementation.  For  this  and  other 
reasons,  C4I  data  ean  be  difficult  to  translate  into  a  form  acceptable  to  an  M&S  system, 
and  viee-versa. 

Over  the  past  deeade,  both  eommunities  have  begun  to  reeognize  the  tremendous  poten¬ 
tial  improvements  in  capability  that  could  be  realized  if  C4I  systems  and  M&S  systems 
could  interoperate  more  effectively.  The  following  examples  are  often  cited  as  benefits  of 
interoperability: 

•  Simulation-based  acquisition  (i.e.,  requirements  development  and  analysis;  test¬ 
ing;  and  training) 

•  Development  of  doetrine  and  tacties  teehniques  and  proeedures 

•  Embedded  training  (both  individual  and  colleetive) 

•  Course-of-action  development  and  analysis 

•  Mission  planning  and  rehearsal 

•  Exeeution  monitoring 

Unfortunately,  there  are  some  fundamental  barriers  to  interoperability  in  today’s  state-of- 
the-praetiee. 

1.1  Purpose  of  the  Document 

The  purpose  of  this  study  is  to  present  investigations  into  a  key  area  of  C4I/M&S  inter¬ 
operability.  This  area  is  data/objeet  model  alignment:  the  ability  for  C4I  and  M&S  sys¬ 
tems  to  share  and  exehange  data  based  on  a  shared  semanties  for  the  data  eaeh  system 
manipulates.  A  previous  study  in  this  area  by  the  Institute  for  Defense  Analyses  (IDA) 
yielded  a  preliminary  methodology  for  rigorous  assessment  of  data/object  model  align¬ 
ment  [IDA  2001].  This  study  refines  and  extends  that  methodology  to  make  it  better  de¬ 
fined  and  more  widely  applieable. 

This  study  applies  the  methodology  to  assess  alignment  between  two  prominent  models 
from  the  C4I  and  the  M&S  domains:  NATO's  Eand  Command  and  Control  Information 
Exehange  Data  Model  (EC2IEDM)  [NATO  2000]  and  the  Warfighter’s  Simulation  2000 
(WARSIM),  also  known  as  Joint  Simulation  System  (JSIMS)  Eand  Component.  The 
study  includes  an  assessment  of  alignment  of  environmental  data  as  represented  by  the 
Terrain  Common  Data  Model  (TCDM),  which  is  used  by  JSIMS  and  WARSIM.  This  as¬ 
sessment  reveals  the  status  of  data  alignment  between  representative  C4I  and  M&S  mod- 
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els,  identifies  ehanges  needed  to  bring  these  models  into  better  alignment,  and  provides  a 
basis  for  developing  a  eommon  referenee  objeet  model  eapturing  both  C4I  and  M&S  data 
requirements  to  improve  future  interoperability  between  C4I  and  M&S  systems. 

1.2  Intended  Audience 

There  are  4  intended  audienees  for  this  doeument: 

1 .  LC2IEDM  (and  other  C4I  model)  designers  who  want  interoperability  with  M&S 
systems. 

2.  WARSIM  (and  other  M&S  model)  designers  who  want  interoperability  with  C4I 
data  models. 

3.  Department  of  Defense  (DoD)  oflfeials  responsible  for  establishing  direetions  for 
C4I  and  M&S  systems. 

4.  Individuals  or  organizations  eondueting  alignment  studies  between  disparate  data 
and  objeet  models. 

The  study  results  highlight  some  of  the  issues,  ehoiees,  and  problems  involved  in  translat¬ 
ing  the  data  between  different  models  eonstrueted  for  different  purposes,  even  when  they 
intend  to  deseribe  the  same  universe.  This  information  is  a  prelude  to  development  of  a 
eommon  referenee  model,  and  is  part  of  the  proeess  of  edueating  those  working  to  im¬ 
prove  data  interoperability  between  the  C4I  and  M&S  domains.  The  appendix  that  as¬ 
sesses  alignment  between  WARSIM  and  the  Joint  Data  Model  (JDM)  of  the  Army  Battle 
Command  System  (ABCS)  may  be  of  speeial  interest  to  the  WARSIM  program  whieh  is 
required  to  interoperate  with  ABCS.  However,  the  study  is  not  intended  as  a  eomplete, 
eonelusive  or  authoritative  mapping  of  the  data  between  these  models  (WARSIM  and  the 
LC2IEDM/  JDM). 

This  doeument  assumes  the  reader  is  familiar  with: 

•  Entity-relationship  (ER)  modeling  eoneepts  in  general,  and  the  Integrated  Com¬ 
puter-Aided  Manufaeturing  Definition  One  Extended  (IDEE IX)  [NIST  1993]  no¬ 
tation  in  partieular. 

•  Objeet-oriented  (00)  modeling  eoneepts  in  general,  and  the  Unified  Modeling 
Eanguage  (UML)  [Booeh  1996]  in  partieular. 

•  The  eoneept  of  a  federation  Objeet  Model  (f  OM)  [HLA  2000]. 

However,  the  basie  notation  for  IDEE  IX  and  UML  diagrams  is  presented  for  ease  of  ref- 
erenee  in  Appendix  A. 

1.3  Background 

To  the  extent  that  C4I/M&S  interoperability  exists  today,  it  is  aehieved  mainly  by  ad  hoc 
software  interfaees  established  between  speeifie  systems.  These  interfaees  typieally  han¬ 
dle  a  small  subset  of  the  messages  or  data  neeessary  for  interoperability.  Signifieant  hu¬ 
man  intervention  is  neeessary  if,  for  example,  realism  is  to  be  aehieved  in  a  training  exer- 
eise.  M&S  systems,  for  instanee,  rarely  handle  free  text  messages;  moreover,  they  are  in- 
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herently  at  least  partly  artificial  and  therefore  do  not  have  the  same  constraints  for  mes¬ 
sage  standards,  formats,  and  protocols.  Any  interface  between  a  C4I  system  and  an  M&S 
system  must  recognize  and  overcome  these  differences.  Such  interfaces  can  become 
complex.  They  are  generally  costly  to  develop  and  maintain. 

In  recent  years  there  has  been  some  concerted  effort  to  devise  systematic  approaches  to 
interoperability.  One  of  these  approaches  has  yielded  a  framework  that  lays  out  several 
foundational  areas  in  which  progress  must  be  made  before  interoperability  goals  can  be 
fully  achieved  [HS  2000].  This  framework,  shown  in  Figure  1,  identifies  a  comprehen¬ 
sive  solution  in  terms  of  the  following  components: 

•  Architectures  Alignment,  recognizing  that  there  are  many  possible  solutions.  The 
C4I  community  has  developed  the  Defense  Information  Infrastructure  Common 
Operating  Environment  (DII  COE)  architectures.  The  simulation  community  has 
the  High  Level  Architecture  (HLA)  [HLA2000].  These  architectures  affect  the 
technical  basis  upon  which  C4I  and  simulation  systems  are  built.  Alignment  of  ar¬ 
chitectures  contrasts  and  resolves  the  differences  in  how  architectures  compart¬ 
mentalize  the  “solution  space”  of  the  system(s)  or  system  of  systems. 

•  Common  Data/Object  Models,  i.e.,  the  development  of  models  common  to  both 
C4I  and  M&S  systems.  Having  an  M&S  application  use  the  same  or  similar 
model  representations  as  the  C4I  systems  with  which  it  exchanges  data  minimizes 
translation  and  the  attendant  risks.  [HB  1999]. 

•  Common  Standards  to  use  in  applying  architectures  and  common  data/object 
models  when  constructing  interoperable  systems.  Making  sense  of  where  and  how 
to  apply  standards  relies  primarily  on  work  being  done  on  the  architecture  and 
data/object  model  alignment.  Since  little  architecture  and  model  alignment  work 
has  been  done,  setting  and  using  meaningful  standards  to  assist  interoperability 
challenges  has  been  difficult  to  date. 

•  Reusable  Component  Interfaces,  which  paradoxically  (given  the  relative  lack  of 
activity  in  the  blocks  underneath)  has  been  an  active  research  area.  One  reason  is 
that  interfaces  can  provide  short-term  solutions  that  are  easy  to  envision  and  allow 


Processes 
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Standards 


Architecture 
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Figure  1.  C4I/M&S  Interoperability  Components 
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quick  successes  in  a  world  of  disparate  systems.  Translators  in  these  interfaces 
help  to  convert  data  between  systems,  but  never  really  remove  basic  underlying 
ineompatibilities  of  model  representation  or  arehiteeture  misalignment  in  the 
original  systems. 

•  Processes  for  Alignment,  providing  policies  and  proeedures  for  evolving  the 
other  blocks  in  Figure  1 . 

Suecesses  in  these  foundational  areas  will  lead  to  Shared  Solutions  to  C4I/M&S  interop¬ 
erability,  the  roof  of  this  “house  diagram”.  This  study  concentrates  on  the  Common 
Data/Object  Models  bloek,  contributing  to  the  understanding  of  the  current  state  of  inter¬ 
operability  in  this  area. 

1.4  Data/Object  Model  Alignment 

Data/object  model  alignment  between  C4I  and  M&S  models  is  the  situation  where  infor¬ 
mation  from  the  C4I  data  model  can  be  expressed  in  the  objeet  model  of  the  M&S  system 
without  loss  of  information,  and  vice  versa.  Informally,  alignment  implies  that  if  data 
from  one  system  is  converted  to  the  other  and  back  again,  there  should  be  no  loss  of  in¬ 
formation. 

The  objective  of  data/object  model  alignment  is  to  ereate  an  environment  in  whieh  a  C4I 
system  and  an  M&S  system  can  share  data,  unambiguously  and  without  human  interven¬ 
tion.  In  the  absenee  of  data/object  model  alignment,  interoperability  is  costly,  slow,  or 
both.  If  alignment  exists,  then  (for  example)  an  M&S  system  can  obtain  formation  infor¬ 
mation  from  a  C4I  system  and  use  that  information  as  the  basis  for  simulating  troop  for¬ 
mation.  If  alignment  does  not  exist,  the  M&S  system  will  have  to  rely  on  another  source 
(costly)  or  obtain  the  formation  information  from  a  human  (slow). 

Data/object  model  alignment  alone  does  not  guarantee  interoperability;  it  is  only  one 
eomponent  thereof.  The  aligned  models  must  be  applied  correctly  (Common  Standards). 
Moreover,  as  the  size  of  this  report  should  make  clear,  there  is  great  detail  in  alignment, 
and  unless  that  detail  is  properly  encapsulated  (Reusable  Component  Interfaees)  interop¬ 
erability  will  still  be  complex  and  costly.  Nevertheless,  achieving  data/object  model 
alignment  is  a  signifieant  step  towards  interoperability. 

The  term  “data/object  model  alignment,”  as  used  throughout  this  paper,  is  coneerned  spe- 
cifieally  with  the  alignment  of  data  models  used  for  C4I  data  and  the  object  models  used 
in  M&S  systems.  However,  the  methodology  in  this  report  has  broader  application,  in¬ 
tending  to  apply  to  the  alignment  of  any  entity-relationship  (ER)  model  (traditionally 
used  to  describe  C4I  models)  with  the  class  diagrams  of  any  Object-Oriented  (00)  model 
(traditionally  used  in  M&S  modeling).  It  also  has  obvious  extensions  to  alignment  be¬ 
tween  any  two  models  of  the  same  type  (ER  or  00).  The  methodology  is,  as  Seetion  5 
will  discuss,  adaptable  to  the  nuances  of  the  models  being  studied.  This  maintains  flexi¬ 
bility  and  lets  domain-specifie  knowledge  play  a  role  in  alignment. 
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1.5  Organization  of  this  Document 

This  document  is  organized  as  follows: 

•  Seetion  1  (this  section)  introduces  the  problems  addressed  by  the  study,  presents 
the  study’s  purpose,  and  its  intended  audience. 

•  Seetions  2  and  3  provide  overviews  of  the  data  and  object  models  studied  in  this 
report:  WARSIM,  the  JSIMS  FOM,  the  Terrain  Common  Data  Model  (TCDM), 
and  the  LC2IEDM. 

•  Seetion  4  provides  a  precise  definition  of  what  data/object  model  alignment 
means. 

•  Section  5  gives  the  proeess  used  to  assess  the  alignment  of  the  models.  It  provides 
enough  information  to  repeat  the  results  of  the  study,  or  to  extend  the  results  to  ar¬ 
eas  of  the  models  that  were  not  treated  in  this  study. 

•  Seetion  6  presents  the  first  part  of  the  results  of  the  study:  the  degree  to  which  the 
WARSIM-published  elements  of  the  JSIMS  FOM  align  with  elements  of  the 
LC2IEDM. 

•  Seetion  7  presents  the  second  part  of  the  results:  the  degree  to  which  the 
EC2IEDM  aligns  with  the  WARSIM-published  elements  of  the  JSIMS  EOM. 

•  Section  8  states  reeommendations  for  how  WARSIM  and  the  EC2IEDM  should 
evolve  to  inerease  alignment  and  thereby  improve  interoperability. 

Eollowing  the  body  of  this  doeument  are  six  appendiees.  The  first  (A)  presents  the  nota¬ 
tion  used  in  this  doeument.  The  seeond,  third,  and  fourth  (B-D)  summarize  the  assess¬ 
ments  of  all  unit,  equipment,  and  environment  elements,  respectively.  The  fifth  (E)  details 
the  rules  that  were  used  in  performing  assessments  of  data  alignment  at  the  level  of  the 
specific  values  supported  by  data  elements.  The  sixth  (E)  extends  our  assessment  analysis 
of  WARSIM-C4I  data  compatibility  from  the  LC2IEDM  to  the  Joint  Common  Database 
Data  Model  (JDM)  of  the  Army  Battle  Command  System  (ABCS). 

The  results  reported  in  this  study  summarize  our  detailed  assessments  of  the  alignments 
between  the  many  specifie  modeling  elements  of  WARSIM  and  the  EC2IEDM.  Sinee  the 
complete  details  of  these  assessments  are  too  voluminous  to  include  in  this  report  they  are 
available  separately  in  two  different  formats:  a  set  of  databases  (in  Mierosoft  Access  for¬ 
mat)  and  a  set  of  spreadsheets  (in  Microsoft  Excel  format). 
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2.  Overview  of  WARSIM,  JSIMS,  and  the  TCDM 


2.1  WARSIM 

WARSIM  will  provide  simulation  tools  to  Army  leaders  that  they  ean  use  to  ereate  realis- 
tie  operational  eonditions  for  edueation,  training,  and  mission  rehearsal  to  meet  Title  X 
requirements.  The  program  objeetives  inelude  supporting  Total  Army  and  Joint  Foree 
events  from  Battalion  through  eehelons  above  Corps  in  seenarios  from  aeross  the  opera¬ 
tional  eontinuum  while  redueing  the  resourees  required  to  prepare,  exeeute,  and  assess 
simulation  events.  WARSIM  will  support  real-time  battle  eommand  training  events  sueh 
as  seminars.  Command  Post  Exereises  and  Battle  Command  Training  Program  events  in 
all  type  units  and  sehools. 

The  best  doeumentation  of  current  WARSIM  battlefield  objects  and  attributes  can  be 
found  in  the  WARSIM  managed  parts  of  the  JSIMS  FOM.  Thus,  we  used  WARSIM  man¬ 
aged  elements  in  the  JSIMS  FOM  (Version  6.0)  [JSIMS  2001]  as  the  primary  basis  for 
our  assessment  of  data  alignment  between  WARSIM  and  the  FC2IEDM.  However,  be¬ 
cause  such  FOMs  are  designed  to  document  dynamic  data  that  are  exchanged  by  simula¬ 
tions  during  an  exercise  using  the  DoD’s  High  Fevel  Architecture  (HFA),  the  JSIMS 
FOM  does  not  include  all  the  relevant  terrain  data.  For  that  reason  we  also  included  the 
JSIMS  Terrain  Common  Data  Model  (TCDM)  [JSIMS  1999]  in  our  alignment  assess¬ 
ment. 

2.2  JSIMS  FOM 

JSIMS  is  a  federation  of  many  different  simulations,  including  WARSIM  for  the  Army, 
the  National  Air  Space  Model  (NASM)  for  the  Air  Force,  and  Maritime  for  the  Navy 
[JSIMS  2001].  In  order  to  focus  on  WARSIM  related  elements,  this  alignment  assessment 
is  restricted  to  those  object  classes  (and  their  attributes)  in  the  JSIMS  FOM  for  which 
WARSIM  has  management  responsibility.  Available  resources  were  insufiicient  to  extend 
this  analysis  to  all  of  the  object  classes  to  which  WARSIM  subscribes,  or  to  any  of  the 
interaction  classes  that  have  WARSIM  involvement. 

To  enable  assessment  in  different  modeling  areas,  we  divided  the  analysis  space  into  four 
main  areas:  Unit,  Equipment,  Environment,  and  C4I.  The  Unit  area  of  WARSIM  com¬ 
prises  the  classes  and  inheritance  relations  illustrated  in  Figure  2.  (The  figure  is  drawn 
using  the  Unified  Modeling  Fanguage  (UMF).  See  Appendix  F  for  an  explanation  of  the 
UMF  notation.)  The  Equipment  area  comprises  the  classes  and  inheritance  relations  in 
Figure  3.  Each  class  has  zero  or  more  attributes.  An  attribute  may  be  atomic  (e.g.,  an  in¬ 
teger)  or  a  complex  data  type  (e.g.,  a  3-d  coordinate).  There  is  considerable  overlap  be¬ 
tween  the  Unit  area  and  the  Equipment  area  classes.  This  is  because  all  equipment  infor¬ 
mation  on  platforms  is  stored  in  attributes  of  subclasses  of  the  org  class  (e.g.,  in 
org.land.supply_cache  and  org. land. equip_group)  in  this  model. 
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Figure  2.  Unit  Area  of  WARSIM 

The  only  Environment  area  class  in  the  JSIMS  FOM  that  is  managed,  published,  or  sub¬ 
scribed  to  by  WARSIM  is  minefield. land,  although  many  other  classes  of  environmental  fea¬ 
tures  are  modeled  by  the  TCDM.  Hence,  minefield. land  would  ordinarily  be  the  only  “dy¬ 
namic”  part  of  the  terrain  under  HLA  rules  which  require  all  exchanges  of  FOM  data 
among  federates  to  occur  via  its  Run-Time  Infrastructure  (RTI).  However,  JSIMS  and 
WARSIM  are  using  a  separate  Synthetic  Natural  Environment  (SNE)  federate  which 
models  environmental  changes  through  its  SNE  classes  (chem  bio  strike,  dy- 
namic  feature,  metoc  edit,  smoke  strtke).  Although  WARSIM  does  not  subscribe  to  the 
SNE  classes,  we  have  been  informed  that  it  will  accept  updates  to  this  FOM  data  from 
the  SNE  federate  Application  Program  Interface  (API)  in  violation  of  HLA  rules.  Opera¬ 
tor  intervention  may  also  change  the  terrain  during  execution  according  to  our  sources. 
Hence,  some  of  the  terrain  elements  from  the  TCDM,  which  are  discussed  in  the  next  sec¬ 
tion,  may  also  change  dynamically  for  WARSIM  during  a  simulation  exercise. 

The  C4I  area  consists  of  C4I  initialization  classes  and  “C2_artifacts”  classes.  They  were 
not  included  in  the  assessment  because  they  contain  only  data  peculiar  to  specific  C4I 
system  interfaces  and  do  not  contain  battlefield  information. 


^  Information  on  dynamic  terrain  in  WARSIM  provided  by  representatives  of  the  Environmental  Data¬ 
base  Integrated  Product  Team  (EDB  IPX). 
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Figure  3.  Equipment  Area  ofWARSIM 


2.3  TCDM 

The  TCDM  describes  the  terrain  component  of  the  JSIMS  SNE.  The  TCDM  includes  fea¬ 
tures  that  will  be  represented  in  the  JSIMS  Terrain  Database.  This  study  used  TCDM  Re¬ 
vision  1.2a  [JSIMS  1999]  because  this  was  the  most  recent  version  which  we  were  able  to 
obtain  at  the  outset  of  the  study. 

The  TCDM  is  a  logical  data  model  that  addresses  both  low  and  medium  resolution  simu¬ 
lation  requirements.  It  was  designed  to  be  extensible  to  accommodate  high-resolution  re¬ 
quirements.  The  TCDM  supports  both  virtual  and  constructive  simulations  at  the  platform 
and  aggregate  levels  of  resolution.  The  TCDM  was  built  on  the  Environmental  Data  Cod¬ 
ing  Specification  (EDCS)  [RMES  2000],  and  will  be  used  by  JSIMS  to  specify  terrain 
database  content  requirements,  and  for  the  development  of  the  terrain  databases. 

The  design  of  the  TCDM  was  driven  by  the  needs  of  the  warfighter  and  military  modeler 
to  represent  concepts  of  interest,  as  well  as  a  requirement  for  elficient  runtime  reasoning 
about  the  SNE  in  the  context  of  a  military  model.  These  needs  implied  organizational  and 
representational  requirements  for  the  data  model. 

Analyses  based  on  model  resolution,  use,  consistency,  and  performance  led  to  the  deci¬ 
sion  to  use  feature  representations  rather  than  geometric  representations  in  the  data 
model.  The  resulting  TCDM  is  organized  into  thematic  layers,  called  coverages.  Cover¬ 
ages  align  with  how  subsets  of  terrain  features  would  be  represented  and  processed. 
Within  each  coverage  the  data  model  is  fiat  (except  for  Surface  Areas,  which  has  four 
subcoverages).  The  coverages  and  subcoverages  are; 

•  Surface  Areals 
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•  Physiography 

•  Vegetation 

•  Urban 

•  Water 

•  Point  Culture 

•  Linear  and  Point  Hydrography 

•  Linear  and  Areal  Terrain  Obstacles 

•  Maritime  Traflhcability 

•  Linear  Connectivity/Distribution 

•  Linear  and  Point  Transportation 

•  Metadata 

•  Geotile  Reference 

•  Administrative  Boundaries 

•  Battlefield  Elements 


The  Geotile  Reference  coverage  is  used  only  for  database  generation.  It  contains  eleva¬ 
tion  profiles  along  the  Geotile  Reference  System  (GTRS)  geotile  boundaries.  The  Meta¬ 
data  coverage  is  used  to  characterize  the  data  source  used  in  populating  Surface  Areals 
regions. 


Within  a  coverage  most  features  share  a  consistent  attribute  set.  The  TCDM  specifies  the 
data  type  for  each  attribute,  the  range  of  allowable  values,  and  in  some  cases,  a  default 
value  for  an  attribute.  For  enumerated  data  types  a  complete  set  of  enumerations  is  pro¬ 
vided. 
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3.  Overview  of  the  LC2IEDM 


The  version  of  the  LC2IEDM  used  in  this  assessment  eorresponds  to  the  release  of  3 1 
March  2000  by  the  Army  Tactical  Command  and  Control  Information  System  (ATCCIS) 
group.  It  contains  149  entities,  ten  of  which  are  independent:  ACTION,  CANDIDATE-TARGET- 
LIST,  CAPABILITY,  CONTEXT,  LOCATION,  OBJECT-ITEM,  OBJECT-TYPE,  REFERENCE, 
REPORTING-DATA,  and  RULE-OF-ENGAGEMENT.  Figure  4  shows  the  high-level  relationships 
among  these  entities  using  the  IDEFIX  notation  [NIST  1993].  The  supertype  entity 
OBJECT-ITEM  contains  the  five  battlefield  objects  FACILITY,  FEATURE,  MATERIEL, 
ORGANISATION  and  PERSON,  whereas  the  supertype  entity  OBJECT-TYPE  provides  the  cor¬ 
responding  hierarchy  for  their  classes,  namely  FACILITY-TYPE,  FEATURE-TYPE,  MATERIEL- 
TYPE,  ORGANISATION-TYPE  and  PERSON-TYPE. 

3.1  Background 

The  EC2IEDM  was  developed  by  ATCCIS  to  support  land  C2  operations  in  a  multina¬ 
tional  environment  for  echelons  to  include  brigade,  corps,  and  above.  It  therefore  empha¬ 
sizes  the  data  that  national  armies  would  share  under  such  conditions  and  purposely 
leaves  out  those  details  that  may  traditionally  be  handled  by  national  C2  systems,  such  as 
personnel-related  information.  The  model  also  reflects  the  philosophy  that  planning 
documents  must  be  boiled  down  to  the  specific  actions  contained  therein,  and  mapped  to 
WHO  does  the  action,  against  WHOM,  with  WHAT,  WHERE,  and  WHEN.  In  addition, 
the  model  permits  the  specification  of  contextual  data  via  REPORTING-DATA,  REFERENCE, 
and  CONTEXT. 

3.2  Current  Status  of  the  LC2IEDM 

The  EC2IEDM  is  the  fourth  version  of  the  original  ATCCIS  model,  the  Generic  Hub 
(GH).  It  is,  therefore,  also  referred  to  as  GH4.  A  fifth  version  of  the  Generic  Hub  model 


Figure  4.  High-Level  Depiction  of  the  LC2IEDM  Independent  Entities 


11 


(GH5)  was  released  in  the  summer  of  2002,  but  as  of  this  writing  it  has  not  been  adopted 
by  NATO  as  the  basis  for  the  LC2IEDM.  The  major  ehanges  in  GH5  with  respeet  to  GH4 
are  additional  struetures  needed  to  support  Military  Operations  Other  than  War 
(MOOTW),  as  well  as  extensions  to  interfaee  with  naval  and  air  operations.  NATO  has 
adopted  the  LC2IEDM  as  the  reference  model  for  land  C2.  In  the  Einited  States,  there  are 
currently  initiatives  to  use  the  model  as  the  point  of  departure  to  support  interoperability 
among  services  and  agencies.  The  initial  version  of  the  Generic  Hub  (GH)  was  used  in 
1993  to  develop  DoD's  C2  Core  Data  Model  (C2CDM),  now  part  of  the  DoD  Data  Archi¬ 
tecture  (DDA).  The  Army's  Joint  Common  Database  (JCDB),  currently  in  version  5.0, 
was  built  from  the  C2CDM,  and  it  incorporated  data  structures  from  GH3,  as  well  as 
from  other  Army  information  systems. 
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4.  Definition  of  Alignment 


This  section  presents  the  meaning  of  data/object  model  alignment  between  the  JSIMS 
FOM  and  the  LC2IEDM.  A  clear,  precise  definition  of  what  data  model  and  object  model 
alignment  means  is  essential.  It  provides: 

•  A  shared  understanding  of  objectives  for  an  alignment  assessment  team. 

•  An  unambiguous  interpretation  of  the  results  of  alignment  assessment. 

The  interoperability  community  generally  agrees  that  data  and  object  models  are  an  im¬ 
portant  component  of  interoperability  [HB  1999],  but  has  yet  to  reach  more  than  an  in¬ 
formal  consensus  on  what  alignment  is.  Everyone  seems  to  agree  that  alignment  is  de¬ 
fined  as  the  ability  for  systems  to  share  information  based  on  commonality  between  their 
data/object  models.  The  ambiguity  lies  in  how  one  determines  commonality.  Commonal¬ 
ity  may  stem  from  syntax,  semantics,  standards,  or  other  sources,  or  combinations 
thereof  Which  sources  are  appropriate  depends  on  factors  such  as  the  elements  one  ana¬ 
lyzes  from  each  model  and  the  models’  completeness. 

In  other  words,  alignment  can  mean  different  things,  depending  on  which  elements  are 
chosen  from  the  models  being  aligned.  All  meanings  share  certain  characteristics,  but  dif¬ 
fer  in  detail.  This  section  defines  four  meanings,  and  explains  how  they  fit  into  this  re¬ 
port. 

Note  that  the  definition  of  data/object  model  alignment  differs  from  the  process  used  to 
perform  an  alignment  assessment.  Section  5  covers  the  latter  topic. 

4.1  Background 

The  original  definition  of  data/object  model  alignment  came  from  IDA’s  study  of 
data/object  model  alignment  between  the  AICDM  and  the  OMSC  [IDA  2001].  The  defi¬ 
nition  in  that  report  was  intended  to  be  a  general-purpose  framework  for  comparing  and 
contrasting  data/object  model  alignment  of  an  ER-based  C4I  data  model  and  an  00- 
based  M&S  model.  However,  we  recognized  that  our  definition  was  based  on  the  model¬ 
ing  elements  specific  to  the  AICDM  and  the  OMSC,  and  that  we  had  not  fully  explored 
data/object  model  alignment.  We  expected  to  extend  the  definition  of  alignment  during 
subsequent  alignment  assessments. 

Our  goal  is  to  provide  a  framework  for  studying  alignment  between  any  ER-based  model 
and  any  00-based  model.  Both  the  AICDM/OMSC  study  and  the  WARSIM/LC2IEDM 
study  began  with  a  complete  ER  model,  its  semantics  fully  specified  (i.e.,  all  information 
necessary  to  convert  the  model  into  a  physical  database  is  provided).  However,  neither 
the  OMSC  nor  the  JSIMS  EOM  has  been  a  fair  representation  of  an  00  model.  The 
OMSC  is  both  syntactically  and  semantically  incomplete.  The  JSIMS  EOM  is  complete. 


13 


but  its  model  is  from  the  High-Level  Arehiteeture  Object  Model  Template  Specification 
[DoD  1998b],  which  uses  a  subset  of  00  modeling  techniques.  For  example: 

•  The  JSIMS  FOM  models  attributes  but  not  methods.  (An  attribute  is  arguably  a 
shorthand  for  a  set/get  method  pair,  but  attributes  do  not  encapsulate  behavior  to 
the  degree  that  methods  do.) 

•  The  JSIMS  FOM  uses  only  single  inheritance,  not  multiple  inheritance. 

•  The  data  types  of  all  attributes  are  either  atomic  or  complex  data  types,  or  lists 
thereof  No  attribute’s  data  type  is  a  class. ^ 

Until  we  have  performed  an  alignment  assessment  including  a  semantically  complete  00 
model  that  uses  these  and  other  00  constructs,  we  must  regard  the  definition  of 
data/object  model  alignment  as  evolving. 

4.2  An  Intuitive  Definition  of  Alignment 

An  alignment  assessment  is  conducted  to  determine  whether  ER  elements  (views,  enti¬ 
ties,  relationships,  attributes,  and  domains)  align  with  00  elements  (packages,  classes, 
attributes,  and  data  types),  and  vice  versa,  thereby  increasing  the  ease  with  which  an 
M&S  system  and  a  C4I  system  can  interoperate.  What,  then,  does  it  mean  to  say  elements 
are  or  are  not  aligned? 

Intuitively,  elements  are  aligned  if  data  expressed  by  an  element  in  one  model  can  be 
translated  to  the  other  model,  then  translated  back  again  with  no  loss  of  information — in 
mathematical  terms,  if  a  mapping  exists  from  elements  of  one  model  to  elements  of  the 
other  that  is  one-to-one  and  “onto”.  More  precisely,  we  say  that  model  B  is  fully  aligned 
with  an  element  E  of  model  A  if  data  expressed  by  E  can  be  translated  into  model  B  and 
back  again  with  no  loss  of  information.  Eor  example,  if  system  A  models  information 
about  a  tank — its  weight,  current  velocity,  and  current  ammunition  supply,  say — then 
data/object  model  alignment  implies  that  there  exists  a  mapping  from  system  A’s  model 
to  system  B’s  model  such  that  system  B  can  record  the  same  three  pieces  of  information. 
Moreover,  the  existence  of  the  reverse  mapping  implies  that  no  translation  errors  were 
made:  there  was  no  loss  of  precision  or  unintentional  change  in  units  of  measure. 

Alignment  under  this  intuitive  definition  is  neither  necessary  nor  sufficient  for  interop¬ 
erability.  It  is  not  necessary  because  two  systems  may  not  need  symmetry:  we  can  con¬ 
ceive  of  a  situation  where  system  B  takes  data  from  system  A  but  does  not  return  it  (e.g., 
logging  C4I  data  generated  by  an  M&S  system).  We  consider  this  situation  unimportant, 
however,  because  our  interest  is  in  developing  and  promoting  standards  for  C4I  and 
M&S,  and  we  feel  that  standards  are  most  useful  if  they  cover  the  more  general  case  of 
C4I/M&S  two-way  interaction. 

The  intuitive  definition  is  not  sulficient  because  there  is  no  guarantee  that  the  data  from  A 
translated  into  system  5  is  in  a  form  meaningful  to  B:  imagine  an  ER  model  set  up  to 
store  information  without  regard  to  semantics  (the  EC2IEDM  has  such  a  schema  for  ob- 


^  However,  the  data  type  id_c  eontains  a  federation  objeet  identifier.  An  attribute  whose  data  type  is  id_c 
ean  referenee  a  elass  instanee. 
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ject  types).  For  example,  if  B  has  a  single  high  level  object  class  for  any  type  of  object 
and  it  has  an  object  type  name  attribute,  then  any  type  of  entity  from  A  can  be  represented 
in  B,  although  B  itself  may  have  no  definitions  for  any  objects  from  A.  In  such  a  case,  the 
initial  intuitive  definition  could  yield  as  assessment  that  B’s  classes  are  fully  aligned  with 
A’s  entities,  despite  the  fact  that  there  are  no  classes  defined  in  B  whose  semantics  are 
equivalent  to  the  entities  of  A  (see  Section  4.5.4  for  more  detailed  discussion  of  this  is¬ 
sue).  Symmetric  translation  may  enable  the  interchange  of  data,  but  data/object  model 
interchange  is  only  one  part  of  C4I/M&S  interoperability.  In  the  interest  of  promoting 
standards,  we  desire  that  data/object  model  alignment  account  for  shared  semantics  so 
that  data  from  multiple  sources  in  multiple  systems  all  has  the  same  meaning. 

Any  explication  of  semantics  depends  on  the  modeling  elements  used  to  express  it.  The 
LC2IEDM  is  an  ER  model.  The  JSIMS  EOM  uses  00  modeling.  One  issue  in  defining 
alignment  is  the  identification  of  suitable  sets  of  elements  to  align.  Eor  example: 

•  We  can  align  entities  in  an  ER  model  to  classes  in  an  object  model.  Roughly 
speaking,  this  concerns  matching  things  that  model  the  same  types  of  physical  or 
virtual  objects.  Eor  example,  the  EC2IEDM  contains  an  entity  named 
ORGANISATION,  and  the  JSIMS  EOM  contains  a  class  named  org.  To  say  these  two 
elements  align  fully  is  to  say  that  they  model  the  same  thing,  i.e.,  that  an  instance 
of  ORGANISATION  models  the  same  information  as  an  instance  of  org. 

•  We  can  align  attribute  domains  in  an  ER  model  to  data  types  in  an  object  model. 
This  is  a  set  intersection  issue.  Eor  example,  some  EC2IEDM  attributes  have  a 
domain  of  NUMBER(15)  (an  integer  of  15  decimal  digits),  and  some  JSIMS  EOM 
attributes  have  a  data  type  of  long  (a  signed  32-bit  integer).  The  possible  values 
type  long  account  for  just  over  0.002%  of  the  possible  values  of  NUMBER(15). 

These  two  examples  imply  a  correlation  between  element  granularity  and  alignment  rigor. 
Algebraic  theory  can  be  used  to  determine,  rigorously,  if  an  attribute  domain  and  a  data 
type  are  aligned:  a  fully  faithful  (one-to-one  and  onto)  mapping  exists  between  them.  But 
what  does  it  mean  to  say  an  entity  is  aligned  with  a  class?  The  informal  definition  above, 
about  representing  the  same  physical  or  virtual  objects,  still  leaves  room  for  interpreta¬ 
tion. 

Alignment  rigor  forms  a  spectrum.  One  end  is  abstract  and  comprises  high-level  con¬ 
cepts.  The  other  end  is  detailed  and  has  mathematical  rigor  suited  to  formal  reasoning  and 
computer-based  implementations.  In  between  are  levels  of  increasing  formality. 

We  therefore  partition  alignment  rigor  into  a  set  of  discrete  levels.  The  set  is  drawn  from 
the  data  elements  in  the  models.  We  consider  all  data  modeling  elements  available,  and 
place  them  along  a  spectrum  in  terms  of  their  granularity.  The  elements  in  ER  and  00 
models  lead  us  to  identify  four  levels:  Conceptual  (level  1),  Entity  (level  2),  State  (level 
3),  and  Value  (level  4).  They  are  summarized  in  Table  1  (Section  4.4  provides  the  com¬ 
plete  definition).  When  we  speak  of  alignment,  we  refer  to  a  particular  level  if  not  to 
whole  models. 
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There  is  a  pattern  to  the  levels:  Eaeh  alignment  level  is  defined  in  terms  of  the  next  low¬ 
est  level.  In  levels  1-3,  level  i  contains  a  set  of  names  of  elements  that  are  the  focus  of 
level  z  +  1.  For  instance: 

•  In  level  1,  an  00  package  includes  a  set  of  class  names.  Classes  are  the  focus  of 
level  2  in  the  00  model. 

•  In  level  2,  an  ER  entity  contains  attribute  names.  Attributes  are  the  focus  of  level 
3  in  the  ER  model. 


This  hierarchical  approach  has  important  consequences  during  alignment  assessment. 

Table  1.  The  Four  Levels  of  Alignment 


Level 

Participating  Model  Entities 

OO  Model 

ER  Model 

1  Conceptual: 
Entities  of 

user 

perception 

Package 

•  Name 

•  Description 

•  Set  of  class  names 

•  Focal  class  name 

•  Associations  (inheritance,  composition) 

View 

•  Name 

•  Description 

•  Set  of  entity  names 

•  Focal  entity  name 

•  Relationships 

2  Entity: 
Entities  of 
data  model 

Class 

•  Name 

•  Description 

•  Set  of  attribute  names 

Entity 

•  Name 

•  Description 

•  Set  of  attribute  names 

3  State: 
Descriptions 
of  entity  state 

Attribute 

•  Name 

•  Description 

•  Data  type  name 

Attribute 

•  Name 

•  Description 

•  Domain  name 

4  Value: 
Descriptions 
of  domains 

Atomic  Data  Type 

•  Name 

•  Set  of  values  (discrete  or  continuous) 

Attribute  Domain 

•  Name 

•  Set  of  values  (discrete  or 
continuous) 

4.3  Degree  of  Alignment 


Simply  stating  that  two  models  are  or  are  not  aligned  is  not  especially  useful.  If  two  mod¬ 
els  are  not  perfectly  aligned — the  expected  situation — ^we  want  to  know: 

•  Where  are  they  not  aligned?  What  elements  in  one  model  cannot  be  modeled  in 
the  other,  either  in  whole  or  in  part? 

•  To  what  extent  are  they  not  aligned?  Will  minor  changes  bring  the  models  into 
full  alignment,  or  will  significant  design  changes  be  needed? 

•  What  changes  would  improve  alignment!  What  data  elements  in  each  model 
should  be  modified?  What  elements  should  be  added?  Are  there  elements  that  are 
not  aligned  but  should  be  ignored? 

To  help  answer  these  questions  in  quantitative  terms,  we  introduce  the  concept  of  degree 
of  alignment.  Degree  of  alignment  is  a  measure  of  the  percentage  of  elements  of  one 
model  that  align  with  elements  an  another.  It  gives  assessors  some  idea  of  how  much  a 
model  must  change  to  achieve  full  data/object  model  alignment.  It  also  helps  them  under- 
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stand  how  a  change  to  a  model  affects  alignment  with  respeet  to  another:  more  aligned, 
less  aligned,  or  not  at  all. 

Alignment  assessment  ean  be  seen  as  a  proeess  of  identifying  elements  from  both  models 
that  seem  related,  and  then  earefully  eonsidering  whether  one’s  initial  impressions  are 
eorreet.  Degree  of  alignment  is  the  result  of  sueh  eonsideration. 

An  assessor  assigns  a  degree  of  alignment  to  eaeh  pairing  of  ER  and  00  elements  he  as¬ 
sesses.  The  assignment  is  made  with  respeet  to  one  model  or  the  other.  For  example,  one 
result  of  the  alignment  assessments  in  the  LC2IEDM/JSIMS  FOM  study  is  that  the 
JSIMS  FOM  elass  org.land.equip_group  has  a  degree  of  alignment  of  78%  with  respeet  to  the 
FC2IEDM.  This  means  that  of  all  the  data  elements  that  make  up  an  equipment  group, 
roughly  22%  cannot  be  modeled  by  the  FC2IEDM.  Beeause  software  systems  are  fussy 
about  even  small  bits  of  missing  data,  a  degree  of  alignment  of  78%  indicates  that  inter¬ 
operability  between  WARSIM  and  an  FC2IEDM-based  system  is  unlikely. 

Degree  of  alignment  does  not  neeessarily  eorrelate  to  the  effort  needed  to  improve  inter¬ 
operability.  Sometimes  alignment  ean  be  inereased  by  simply  adding  an  attribute  to  a 
elass.  Other  times,  inereasing  alignment  requires  significant  structural  changes  to  a 
model,  ehanges  that  might  neeessitate  review  by  working  groups  and  implementors.  De¬ 
gree  of  alignment  does  not  aeeount  for  sueh  distinetions. 

A  degree  of  alignment  of  100% — known  as  perfect  alignment — is  not  always  neeessary. 
An  M&S  system  typically  generates  huge  amounts  of  state  information  that  a  C4I  system 
need  not  eapture,  for  example.  Assessors,  on  determining  the  degree  of  alignment,  must 
deeide  whether  or  not  it  indieates  sulfieient  interoperability. 

The  methods  an  assessor  uses  to  assign  a  degree  of  alignment  depend  on  the  alignment 
level.  The  Coneeptual  level  is  abstraet,  leaving  an  assessor  few  eonerete  details  with 
whieh  to  reason  about  alignment;  therefore,  a  degree  of  alignment  assigned  to  a  Coneep- 
tual  assessment  is  neeessarily  done  intuitively.  The  Entity  level  is  slightly  less  abstraet,  so 
the  degree  of  alignment  is  assigned  less  intuitively;  the  State  level,  even  less  intuitively. 
At  the  Value  level,  the  assessor  uses  unambiguous  methods  to  assign  a  degree  of  align¬ 
ment.  The  methods  used  for  the  FC2IEDM/JSIMS  FOM  assessment  are  presented  in  Ap¬ 
pendix  E. 

It  is  desirable,  then,  to  perform  Value-level  assessments,  as  they  inspire  the  most  eonfi- 
denee  that  the  assessment  was  done  rigorously.  Performing  Value-level  assessments  is  not 
always  possible  or  neeessary  (see  [WHEH  2001]),  although  it  was  usually  praetieal  in  the 
FC2IEDM/JSIMS  FOM  study. 

Entity-,  State-,  and  Value-level  assessment  are  performed  in  eontext.  A  Value-level  as¬ 
sessment  might  eompare  NUMBER(15)  and  long,  but  this  eomparison  is  unenlightening 
without  knowledge  of  the  ER  and  00  attributes  whose  domain  and  data  type  NUMBER(15) 
and  long  represent.  Value-level  assessment  is  therefore  performed  in  the  eontext  of  a  State- 
level  assessment;  in  fact,  as  discussed  above,  alignment  levels  1-3  are  defined  in  terms  of 
the  next  lower  level.  Eaeh  Value-level  assessment  ean  be  therefore  traeed  to  a  State-level 


17 


assessment,  whieh  in  turn  can  be  traced  to  an  Entity-level  assessment,  which  in  turn  can 
be  traced  to  a  Conceptual-level  assessment.  See  Figure  5. 

Figure  5  illustrates  another  concept  regarding  degree  of  alignment.  When  an  assessor  per¬ 
forms  an  assessment,  the  assessor  assigns  a  degree  of  alignment  based  on  a  study  of  ele¬ 
ments  relevant  to  that  level.  Conceptual-level  elements  are  more  abstract  than  Entity- 
level  elements.  A  degree  of  alignment  assigned  based  on  Conceptual-level  analysis 
should  be  less  rigorous  than  a  degree  of  alignment  assigned  from  Entity-level  analysis. 
For  analogous  reasons,  an  degree  of  alignment  based  on  Entity-level  analysis  is  less  rig¬ 
orous  than  a  degree  of  alignment  assigned  from  State-level  analysis,  which  in  turn  is  less 
rigorous  than  a  degree  of  alignment  assigned  from  Value-level  analysis.  It  is  desirable  to 
incorporate  the  rigor  of  Value-level  analysis  into  Conceptual-level  analysis.  Therefore, 
Conceptual-,  Entity-,  and  State-level  alignment  assessments  have  a  rolled-up  degree  of 
alignment  that  is  computed  from  degrees  of  alignment  of  lower-level  assessments.  The 
rolled-up  degree  of  alignment  for  an  assessment  is  based  on  all  assessments  of  which  it  is 
the  ancestor.  In  our  studies,  we  have  averaged  degrees  of  alignment  from  child  assess¬ 
ments  to  compute  the  rolled-up  degree  of  alignment. 

The  computed  degree  of  alignment  is  important  because  it  tends  to  be  less  subjective  than 
the  assigned  degree  of  alignment.  The  assigned  degree  of  alignment  for  an  element  comes 
from  studying  the  element,  but  the  computed  degree  of  alignment  comes  from  studying 
what  that  element  comprises;  in  other  words,  the  computed  degree  of  alignment  comes 
from  more  detailed,  lower  level  analysis.  Furthermore,  it  is  computed  from  standard  for¬ 
mulas,  whereas  (particularly  at  higher  levels)  the  assigned  degree  of  alignment  comes 
from  intuition.  For  these  reasons,  the  computed  degree  of  alignment  is  used  as  the  final 
value  for  an  alignment  assessment. 
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^“Roll  up”  from  lower  level  assessment 
Figure  5.  Notional  Assessment  Context 
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4.4  Rigorous  Definition  of  Alignment 

This  section  presents  the  complete  definition  of  data/object  model  alignment  as  used  in 
the  LC2IEDM/JSIMS  FOM  study.  It  covers  the  meaning  of  alignment  for  each  of  the 
four  levels.  Discussion  of  each  level  is  broken  into  four  parts: 

1 .  Definition  of  level:  A  conceptual  exposition  of  alignment  assessment  at  the  level. 

2.  Interpretation  in  the  ER  Model:  The  ER  elements  that  appear  in  the  level. 

3.  Interpretation  in  the  00  Model:  The  00  elements  that  appear  in  the  level. 

4.  Meaning  of  alignment:  What  it  means  to  say  that  the  ER  model  and  the  00  are 
aligned  with  respect  to  the  level. 

The  details  of  how  an  assessor  assigns  or  computes  a  degree  of  alignment  are  process- 
specific,  and  are  covered  in  Section  5. 

4.4.1  Conceptual  Level 

4.4. 1.1  Definition  of  Level 

A  concept  is  a  mental  abstraction.  The  Conceptual  level  is  concerned  with  the  highest 
level  abstractions  one  uses  when  thinking  about  a  system,  as  well  as  the  components  of 
those  abstractions.  For  instance,  when  someone  thinks  about  an  automobile,  they  think  of 
wheels,  a  chassis,  and  an  engine.  When  they  think  of  a  military  unit,  they  think  of  a  group 
of  people  and  equipment.  They  may  also  think  of  properties  of  the  system,  such  as  the 
velocity  of  an  automobile,  and  the  location  of  a  military  unit. 

The  Conceptual  level  helps  people  imagine  a  system  and  its  concept  of  operations.  They 
want  a  general  understanding  of  the  elements  in  the  system. 

4.4. 1.2  Interpretation  in  the  ER  Model 

An  ER  model  models  a  concept  as  a  set  of  entity  names,  along  with  the  names  of  the  ER 
relationships  that  associate  them,  and  an  informal  (textual)  definition  of  intended  seman¬ 
tics.  In  ER  modeling,  the  usual  name  for  this  aggregate  is  a  view.  A  view  has  a  name  that 
suggests  what  it  models. 

Typically,  one  entity  in  a  view  is  a  “focal”  entity.  It  contains  the  key  associations  to  other 
entities  in  the  view.  Often,  its  name  suggests  the  whole  concept.  For  example,  the 
EC2IEDM  has  a  view  named  Unit.  This  view  contains  an  entity  named  UNIT.  It  contains 
other  entities  with  attributes  relevant  to  modeling  a  unit,  such  as  ORGANISATION, 
ORGANISATION-TYPE,  and  ORGANISATION-STATUS.  From  the  names  of  these  entities,  it 
should  be  clear  that  UNIT  is  the  one  most  central  to  the  view.  UNIT,  then,  is  the  focal  entity 
of  the  Unit  view. 
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The  LC2IEDM  contained  many  predefined  views,  but  we  mostly  ignored  them.  The  pre¬ 
defined  views  partition  LC2IEDM  entities  into  sets  that  focus  on  something  narrower 
than  a  Concept,  usually  those  attributes  most  relevant  to  a  single  entity.  Typical  is  the 
0RGANISATI0N-ALS19s  view,  shown  in  Eigure  6.  It  contains  only  ORGANISATION  entity  and 
its  the  supertypes  and  subtypes.  Status,  association,  and  type  information  are  partitioned 
into  separate  views.  The  information  in  Eigure  6  shows  the  rudimentary  structure  of  an 
organization,  but  it  omits  aspects  of  the  concept  important  to  alignment  assessment. 

We  therefore  created  our  own  views  to  perform  alignment  assessment.  These  views 
tended  to  be  broader  than  the  predefined  EC2IEDM  views.  Indeed,  they  often  include 
elements  simply  to  help  them  align.  As  an  example,  Eigure  7  shows  the  structure  of  the 
basic  elements  of  the  Unit  view  actually  used  in  alignment  assessment."^  Note  that  the 
view  is  named  Unit,  not  Organization,  which  better  reflects  what  is  being  assessed.  And, 
the  view  does  not  contain  POST  or  CONVOY,  these  entities  being  outside  the  scope  of  a 
unit. 

In  this  study,  we  chose  views  that  correspond  to  natural  divisions  of  the  battlefield  objects 
as  well  as  to  the  division  of  labor  in  the  actual  analysis,  design,  and  implementation  of  the 
WARSIM  software.  Just  as  model  designers  and  developers  find  it  useful  to  organize 
their  models  into  views  or  packages  (in  00  models),  it  is  also  useful  to  have  alignment 
assessment  results  so  organized.  The  main  conceptual  level  views  used  are  Unit,  Equip¬ 
ment,  Environment,  and  C4I,  corresponding  to  areas  of  WARSIM  software  development. 

4.4. 1.3  Interpretation  in  the  00  Model 

In  an  00  model,  a  concept  is  a  package.  A  package  has  a  name  and  a  description,  and 
consists  of  a  set  of  class  names,  plus  the  associations  among  the  classes.  Each  class  has  a 
name  and  an  informal  (textual)  definition.  Analogous  to  the  ER  model,  one  class  is  typi¬ 
cally  a  focal  class.  Eor  example,  the  JSIMS  EOM  concept  of  a  unit  is  a  package  that  in¬ 
cludes  a  class  hierarchy:  org,  org.land,  and  org. land. unit.  The  org. land. unit  class  is  the  focal 
class  of  the  package  (see  Eigure  2  on  p.  8). 

Not  all  packages  have  a  focal  class.  We  identified  a  Terrain  package  containing  TCDM 
features,  but  the  TCDM  has  no  single  feature  that  connotes  a  terrain. 

A  package  has  associations  between  its  classes:  If  two  classes  are  part  of  the  same  con¬ 
cept,  their  designer  probably  considered  the  structural  relationships  between  them.  The 
JSIMS  EOM  uses  three  types  of  associations: 

I .  Inheritance:  Any  class  can  be  a  superclass  of  one  or  more  classes.  Each  subclass 
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Figure  6.  LC2IEDM  ORGANISATION-ALSl9s  View 
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Figure  7.  LC2IEDM  Basic  Unit  View  Used  in  Alignment  Assessment 
inherits  all  the  attributes  of  its  superelass. 

2.  Aggregation:  An  attribute’s  data  type  ean  be  a  complex  data  type.  A  eomplex  data 
type  is  identieal  to  a  elass,  exeept  that  it  ean  have  aggregation  relationships  but 
not  inheritanee  relationships. 

3.  Federation  Object:  Many  JSIMS  FOM  attributes  are  of  type  id_c  (the  “_c”  suffix 
is  a  naming  eonvention  that  identifies  a  data  type  as  a  eomplex  data  type).  This 
type  holds  an  identifier  that  is  reeognized  throughout  a  federation  as  identifying  a 
JSIMS  FOM  objeet  instanee.  A  federation  permits  aecess  to  an  objeet  instanee  via 
this  identifier. 


Note  that  the  first  two  assoeiations  are  statie,  whereas  the  third  is  dynamie.  The  data  type 
of  the  objeet  instanees  represented  by  an  id_c  eannot  be  eheeked  until  a  simulation  is  exe- 
euting. 


The  transitive  elosure  of  these  assoeiations  forms  the  eontent  of  a  paekage  defined  as  fol¬ 
lows.  If  a  JSIMS  FOM  elass  C  is  part  of  a  paekage,  then  the  paekage  must  also  include 
the  transitive  closures  of  C 's  superclass,  if  any;  all  complex  data  types  associated  with  C 
and  its  superclasses;  and  classes  referenced  by  federation  object  identifiers.  (Transitive 
closure  is  not  generally  a  good  rule  for  forming  a  package,  but  it  works  in  the  JSIMS 
FOM  where  classes  that  should  be  in  distinct  packages  are  linked  by  federation  object 
identifier,  not  by  aggregation  or  inheritance.) 

The  JSIMS  FOM  has  no  predefined  packages.  The  packages  used  in  alignment  assess¬ 
ment  were  created  based  on  our  perception  of  conceptual  similarity. 

The  TCDM  does  not  explicitly  express  inheritance  among  features.  Relationships  among 
features  are  expressed  implicitly  through  coverage  membership  and  military  functional 
use,  as  discussed  in  Section  3  of  [JSIMS  1999].  Certain  features  have  a  Complex  Component 
Identifier  attribute  that  relates  features  participating  in  aggregations. 


4.4. 1.4  Meaning  of  Alignment 

An  ER  model  and  an  00  model  align  with  respect  to  a  concept  to  the  degree  that  both 
can  model  that  concept.  A  00  concept  is  modeled  as  a  package,  and  an  ER  concept  as  a 
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view.  To  say  that  the  00  model  and  the  ER  model  align  fully  with  respect  to  a  concept  is 
to  say  that  all  of  the  following  statements  are  true; 

•  There  exist  a  package  and  a  view  that  capture  the  same  concept. 

•  The  descriptions  of  the  package  and  the  view  indicate  that  they  model  identical 
information. 

•  For  each  class  in  the  package,  there  exists  an  ER  entity  (or  set  of  entities)  that 
models  the  same  thing. 

•  For  each  entity  in  the  view,  there  exists  a  class  or  complex  data  type  (or  set 
thereof)  in  the  package  that  models  the  same  thing. 

•  The  associations  in  the  package  and  the  view  relate  information  in  identical  ways. 
In  other  words,  information  stored  in  one  model  can  be  converted  to  the  other 
model,  then  converted  back  with  the  original  relationships  preserved. 

As  an  example,  consider  aligning  the  JSIMS  FOM  and  the  FC2IEDM  with  respect  to  the 
concept  of  a  unit.  A  JSIMS  FOM  package  modeling  units  (i.e.,  containing  classes  such  as 
org. land. unit)  would  align  with  an  FC2IEDM  view  consisting  of  entities  such  as  UNIT.  The 
org. land. unit  class  is  the  focal  class  of  the  Unit  package,  and  UNIT  is  the  focal  class  of  the 
view;^  since  they  both  model  units,  we  consider  the  focal  entities  aligned.  We  would  also 
want  the  JSIMS  FOM  package  to  include  other  classes  and  complex  data  types  that  seem 
directly  related  to  modeling  units  (e.g.,  org,  org. land).  Similarly,  we  need  to  identify 
FC2IEDM  entities  that  seem  central  to  the  concept  of  a  unit  (e.g.,  ORGANISATION,  OBJECT- 
ITEM,  ORGANISATION-ORGANISATION-ASSOCIATION).  To  determine  alignment,  we  need  to 
see  if  elements  in  each  model  have  corresponding  elements  in  the  other  model.  We  also 
need  to  ensure  that  these  entities  have  correct  relationships  (e.g.,  the  relationship  between 
ORGANISATION  via  ORGANISATION-ORGANISATION-ASSOCIATION  is  many-to-many). 

4.4.2  Entity  Level 

4.4.2. 1  Definition  of  Level 

At  the  Entity  level,  the  focus  is  on  the  individual  entities  that  make  up  a  concept.  Entity 
alignment  resembles  Conceptual  alignment  in  that  Entity-level  elements  (classes  and  enti¬ 
ties)  are  also  concepts.  However,  classes  and  entities  are  more  narrowly  focused  concepts 
than  packages  and  views.  Another  distinction  of  the  Entity  level  is  that  programming  and 
DBMS  languages  implement  operations  on  Entity-level  elements,  but  not  on  Conceptual- 
level  elements.  A  system  exhibiting  C4I/M&S  interoperability  is  likely  to  define  struc¬ 
tures  based  on  Entity-level  elements.  A  software  designer  may  be  particularly  interested 
in  the  degree  to  which  an  Entity-level  element  aligns. 

4. 4. 2. 2  Interpretation  in  the  ER  Model 

In  an  ER  model,  an  entity  (in  the  general  sense  of  the  word)  is  modeled  as  an  ER  entity. 
The  ER  entity  has  a  name,  suggesting  what  it  models,  a  description,  and  a  set  of  attribute 
names.  The  attribute  names  suggest  characteristics  of  the  ER  entity. 


^  This  example  is  somewhat  simplified.  See  Appendix  B  for  a  full  diseussion  of  the  LC2IEDM  view  that 
is  aligned  with  the  Unit  paekage. 


22 


4. 4. 2. 3  Interpretation  in  the  00  Model 

In  an  00  model,  an  entity  is  modeled  as  a  class  or  a  complex  data  type.  These  elements 
have  a  name,  a  description,  and  a  set  of  attribute  names  or,  for  a  complex  data  type,  field 
names. 

4. 4. 2. 4  Meaning  of  Alignment 

The  definition  of  alignment  is  almost  the  same  as  for  the  Conceptual  level.  An  ER  model 
and  an  00  model  align  with  respect  to  an  entity  to  the  degree  that  both  can  model  that 
entity.  To  say  that  an  ER  model  and  an  00  model  align  fully  with  respect  to  an  entity 
means  that  all  of  the  following  statements  are  true: 

•  There  exist  a  class  or  complex  data  type  and  an  (ER)  entity  that  have  the  same  in¬ 
terpretation.  (It  is  permissible  for  an  element  in  one  model  to  align  with  a  set  of 
elements  in  the  other.) 

•  Eor  each  attribute  in  the  class  (or  field  in  the  complex  data  type),  there  exists  an 
attribute  in  the  entity  that  models  the  same  information. 

•  Eor  each  attribute  in  the  entity,  there  exists  an  attribute  in  the  class  (or  field  in  the 
complex  data  type)  that  models  the  same  information. 

If  an  00  model  and  an  ER  model  align  with  respect  to  some  concept,  then  each  class  in 
the  concept  should  align  to  some  set  of  entities  and  relationships  in  the  concept,  and  vice 
versa.  Eor  example,  the  EC2IEDM  UNIT  entity  aligns  with  JSIMS  EOM  org. land. unit  class 
at  the  Entity  level.  See  Eigure  8.  However,  if  UNIT  were  part  of  another  EC2IEDM  con¬ 
cept  L  that  did  not  align  to  the  JSIMS  EOM  Unit  concept,  then  there  would  be  no  Entity- 
level  alignment  between  UNIT  and  org. land. unit  in  the  context  of  L. 

The  additional  information  an  assessor  uses  in  Entity-level  alignment  assessment  (attrib¬ 
ute  names)  may  cause  reconsideration  of  assumptions  made  during  Conceptual-level 
alignment  assessment.  Eor  example,  the  assessor  might  have  inferred  alignment  based  on 
similar  descriptions  of  a  class  and  an  entity,  but  during  Entity-level  alignment  assessment 
the  assessor  may  find  that  a  class  has  attributes  the  entity  lacks,  or  vice-versa.  This  infor¬ 
mation  helps  the  assessor  be  more  precise  in  an  assessment  of  individual  Entity-level 
elements. 


Figure  8.  Relationship  Between  Alignment  Levels 


23 


Both  the  LC2IEDM  and  the  JSIMS  FOM  provide  inheritance.  A  JSIMS  FOM  class  may 
inherit  attributes  from  a  superclass.  An  FC2IFDM  entity  may  have  a  supertype.  Inheri¬ 
tance  has  implications  for  alignment.  A  JSIMS  FOM  class  cannot  be  modeled  in  the 
FC2IFDM  unless  the  attributes  of  its  superclass  can  also  be  modeled;  analogously,  an 
FC2IFDM  entity  cannot  be  modeled  in  the  JSIMS  FOM  unless  the  attributes  of  its  super¬ 
type  can  be  modeled.  Therefore,  an  Fntity-level  element’s  degree  of  alignment  is  influ¬ 
enced  by  that  of  its  super-element.  Section  5  discusses  the  formula  we  use. 

4.4.3  State  Level 

4.4.3. 1  Definition  of  Level 

The  State  level  considers  the  properties  of  entities.  State-level  alignment  means  that  the 
information  contained  in  an  attribute  in  one  model  can  be  represented  by  some  combina¬ 
tion  of  attributes  in  the  other  model. 

4. 4. 3. 2  Interpretation  in  the  ER  Model 
In  an  FR  model,  state  is  modeled  using: 

•  Organic  attributes,  i.e.,  attributes  that  are  not  migrated  from  another  entity  as  a 
foreign  key.  UNIT-FORMAL-ABBREVIATED-NAME  is  an  organic  attribute  in  the 
FC2IFDM. 

•  Attributes  from  many-to-many  relationships  between  entities  that  are  character¬ 
ized  by  uses  of  associative  entities.  These  attributes  fall  into  three  categories: 

1 .  The  foreign  keys  migrated  from  parent  to  child,  which  record  the  existence 
of  a  relationship  between  two  instances  of  entities.  In  the  FC2IFDM,  the 
OBJECT-ITEM-TYPE  entity,  which  captures  the  many-to-many  relationship 
between  OBJECT-ITEM  and  OBJECT-TYPE,  includes  attributes  OBJECT-ITEM-ID 
and  OBJECT-TYPE-ID. 

2.  Additional  attributes  needed  to  make  an  associative  entity’s  key  unique.  In 
the  FC2IFDM,  the  OBJECT-ITEM-TYPE  entity’s  key  also  includes  OBJECT- 
ITEM-TYPE-INDEX. 

3.  Other  attributes  of  an  associative  entity,  which  capture  additional  informa¬ 
tion  about  the  relationship.  In  the  FC2IFDM,  the  ORGANIZATION-FACILITY 
EFFECTIVE  BEGIN  CALENDAR  DATE-TIME  attribute  is  an  example. 

•  Attributes  migrated  from  a  supertype. 

•  Attributes  from  many-to-one  relationships  (e.g.,  the  FC2IFDM  attribute 
REPORTING-DATA-ID). 

Attributes  from  many-to-many  relationships  often  describe  temporal  properties.  That  a 
relationship  exists  between  two  entities  implies  a  certain  association  during  a  specified 
period  of  time.  Organic  attributes  are  more  often  used  to  describe  fundamental,  unchang¬ 
ing  properties  of  an  individual  entity. 

The  distinction  between  the  categories  of  attributes  from  many-to-many  relationships  is 
significant  because  the  first  and  second  categories  exist  as  modeling  artifacts  to  imple¬ 
ment  relationship  existence,  not  to  model  application  data.  For  instance,  an  M&S  applica¬ 
tion  might  want  to  retrieve  the  ORGANIZATION-ACTION-ASSOCIATION-EFFECTIVE-DATE  at- 
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tribute’s  value,  but  it  should  not  need  attributes  of  ORGANIZATION-ACTION-ASSOCIATION  in 
the  first  two  eategories  (such  as  ORGANIZATION-ACTION-ASSOCIATION-INDEX,  which  exists 
only  to  ensure  that  each  record  in  the  ORGANIZATION-ACTION-ASSOCIATION  table  is  unique). 

4. 4. 3. 3  Interpretation  in  the  00  Model 

In  an  object  oriented  model,  state  is  queried  or  modified  using  methods.  This  is  true  of 
WARSIM;  however,  the  JSIMS  FOM  has  no  methods.  Instead,  the  JSIMS  FOM  repre¬ 
sents  the  data  that  object  methods  can  retrieve.  Each  datum  is  an  attribute.  Discussion  is 
limited  to  this  special  case. 

An  attribute  has  a  name,  a  description,  and  a  data  type.  The  JSIMS  FOM  uses  two  kinds 
of  data  types:  atomic  and  complex.  An  atomic  data  type  represents  an  indivisible  datum, 
i.e.,  a  datum  that  is  not  further  decomposable  through  the  modeling  language.  (All 
LC2IEDM  attributes  are  atomic.) 

The  JSIMS  EOM  also  offers  complex  data  types.  A  complex  data  type  is  an  aggregation 
of  attributes.  It  is  similar  to  the  concept  of  a  record  in  most  high-level  programming  lan¬ 
guages.  The  components  of  a  complex  data  type,  and  the  information  associated  with 
them,  are  identical  to  those  of  a  class. 

An  attribute’s  data  type  may  be  atomic  or  a  complex  data  type,  but  it  may  not  be  a  class. 
This  characteristic  differentiates  the  JSIMS  EOM  from  most  object  modeling  technolo¬ 
gies.  However,  federation  object  identifiers  provide  equivalent,  albeit  dynamic,  modeling 
capability. 

JSIMS  EOM  attributes  also  have  cardinality.  Cardinality  specifies  how  many  instances  of 
the  attribute  are  associated  with  an  instance  of  the  class;  this  information  can  affect 
alignment.  Example  cardinalities  include: 

•  1:  Exactly  one  instance  of  the  attribute  is  associated  with  each  class  instance. 

•  O-i:  Zero  or  more  instances  of  the  attribute  are  associated  with  each  class  instance. 
The  JSIMS  EOM  specification  states  that  a  4-byte  integer  is  used  to  store  the 
number  of  instances;  therefore,  the  upper  bound  on  the  possible  number  of  in¬ 
stances  is  2^'  -1 . 

•  l-i:  One  or  more  instances  of  the  attribute  are  associated  with  each  class  instance. 

•  3:  Exactly  three  instances  of  the  attribute  are  associated  with  each  class  instance. 

Some  attributes  also  have  units  (e.g.,  meters,  kilograms).  Elnits  are  important  in  determin¬ 
ing  whether  conversions  are  necessary  or  possible  in  alignment.  Conversions  can  result  in 
loss  of  precision  and  therefore  can  potentially  lower  degree  of  alignment  (although  con¬ 
sideration  of  this  issue  occurs  during  Value-level,  not  State-level,  alignment  analysis). 

4. 4. 3. 4  Meaning  of  Alignment 

Eull  alignment  at  the  State  level  means  that  any  state  expressible  in  one  model  must  be 
expressible  in  the  other  model.  An  00  model  and  an  ER  model  align  to  the  degree  that  an 
attribute’s  value  can  be  stored  in,  and  recovered,  from  the  other  model. 
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Usually  an  atomic  attribute  in  one  model  aligns  to  exaetly  one  atomie  attribute  in  the 
other  model.  For  example,  the  name  attribute  of  JSIMS  FOM  elass  org  and  the  OBJECT- 
ITEM-NAME  attribute  of  LC2IEDM  entity  OBJECT-ITEM  align. 

Sometimes  an  atomic  attribute  in  one  model  aligns  to  several  attributes  in  the  other 
model.  This  ean  oecur: 

•  For  an  attribute  in  a  complex  data  type  that  is  used  by  multiple  classes.  Consider 
the  speed  attribute  of  the  JSIMS  FOM  eomplex  data  type  groundJinear_c.  As  Figure 
9  shows,  it  does  not  direetly  express  the  speed  of  a  FOM  objeet,  but  rather  ex¬ 
presses  that  objeet’s  speed  during  a  given  movement  segment.  Furthermore,  speed 
can  express  the  segment  speed  of  both  an  organization  (if  it  is  derived  from  the 
move_data  attribute  of  elass  org)  or  a  platform  (if  it  is  derived  from  the 
platform_move_data  attribute  of  class  org. land. unit).  In  other  words,  speed  ean  apply  to 
an  organization,  whieh  is  modeled  in  the  LC2IEDM  as  an  instanee  of 
ORGANISATION,  or  it  ean  apply  to  a  platform,  whieh  is  modeled  in  the  EC2IEDM 
as  an  instanee  of  MATERIEL.  The  EC2IEDM  models  organization  speed  using  the 
ORGANISATION-POINT-SPEED-RATE  attribute;  it  models  materiel  speed  using  the 
MATERIEL-POINT-SPEED-RATE  attribute.  The  speed  attribute  therefore  aligns  to  both 
EC2IEDM  attributes.  Of  course,  if  JSIMS  EOM  data  were  converted  to  an 
EC2IEDM  representation,  only  one  of  the  EC2IEDM  attributes  would  model  a 
given  speed. 

•  For  an  attribute  whose  data  type  is  an  enumeration.  Sometimes  the  enumerated 
values  are  split  aeross  multiple  attributes  in  the  other  model.  Eor  example,  the 
JSIMS  EOM  platform_type  attribute,  of  type  platform_type_e,  aligns  to  three 
EC2IEDM  attributes:  COMBAT-UNIT-TYPE-ARM-CODE,  MATERIEL-TYPE-CATEGORY- 
CODE,  and  OBJECT-TYPE-CATEGORY-CODE.  The  reason  is  that  the  union  of  the  three 
EC2IEDM  attributes’  domains  is  neeessary  to  eover  the  values  in  platform_type_e. 

A  JSIMS  EOM  attribute  whose  data  type  is  a  eomplex  data  type  almost  always  aligns  to 
multiple  LC2IEDM  attributes.  In  faet,  beeause  a  eomplex  data  type  is  really  an  entity — it 
models  some  physieal  or  virtual  objeet — the  attribute’s  degree  of  alignment  is  defined  in 


Classes  Complex  Data  Types 


Figure  9.  JSIMS  FOM  Class/Type  Structure  for  Speed 
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terms  of  the  Entity-level  degree  of  alignment  of  the  eomplex  data  type. 

As  Entity-level  alignment  is  defined  with  respect  to  Conceptual-level  alignment,  so  State- 
level  alignment  is  defined  with  respect  to  Entity  Eevel  alignment.  Attribute  Aj  of  class  C 
and  attribute  Ai  of  entity  E  can  only  be  aligned  at  the  State  level  if  C  and  E  are  aligned  at 
the  Entity  level  (more  exactly,  if  E  is  among  the  set  of  entities  that  are  aligned  with  C). 

Some  ER  attributes  align  structurally.  Their  values  are  expressed  by  associations,  rather 
than  attributes,  in  the  00  model.  Structural  alignment  is  characteristic  of  migrated  attrib¬ 
utes.  Eor  example,  the  UNIT-ID  attribute  is  migrated  from  the  ORGANISATION  entity.  Any 
instance  of  unit  therefore  records  the  information  described  by  the  attributes  of 
ORGANISATION.  In  the  JSIMS  EOM,  this  is  handled  by  the  fact  that  class  org. land. unit  is  a 
subclass  of  org. land,  which  is  a  subclass  of  org. 

4.4.4  Value  Level 
4.4.4. 1  Definition  of  Level 

The  Value  level  considers  the  overlap  of  domains.  The  key  issue  is  the  degree  to  which 
values  from  a  data  type  in  one  model  can  be  mapped  to  another  model.  They  may  map 
partially,  fully,  or  not  at  all. 

The  values  in  each  domain  need  not  be  identical.  The  echelon  codes  in  the  JSIMS  EOM 
include  Army  and  Battalion;  in  the  EC2IEDM  they  include  AR  and  BA.  We  consider  these 
codes  equivalent  for  the  purposes  of  data/object  model  alignment  because  it  is  possible  to 
define  an  unambiguous  mapping  between  them. 

Permitting  alignment  via  a  mapping  rather  than  demanding  strict  equivalence  was  a  con¬ 
troversial  decision.  Strict  equivalence  is  preferable;  each  mapping  implies  a  software  de¬ 
velopment  effort  must  be  undertaken.  Each  such  effort  introduces  possibilities  for  imple¬ 
mentation  errors.  However: 

•  Value-level  degree  of  alignment  measures  domain  overlap,  and  a  mapping  ac¬ 
counts  for  overlap. 

•  Penalizing  degree  of  alignment  based  on  differences  in  values  is  difficult;  the 
formulas  we  proposed  seemed  to  say  something  about  effort,  which  degree  of 
alignment  does  not  measure. 

•  Even  if  two  domains  have  the  same  set  of  literals,  there  is  no  guarantee  that  the 
literals  have  the  same  meaning;  e.g.,  two  domains  modeling  terrain  might  both  in¬ 
clude  “creek”  but  intend  different  semantics.  Therefore,  strict  equivalence  is  not  a 
guarantee  of  interoperability.  There  is  always  some  need  for  human  judgment. 

•  The  possibility  of  implementing  a  mapping  means  there  is  no  need  to  change  ei¬ 
ther  of  the  models  to  achieve  data/object  model  alignment. 

The  implication  is  that  degree  of  alignment  measures  the  potential  for  alignment  rather 
than  the  fact.  Achieving  data/object  model  alignment  to  the  measured  degree  may  require 
implementing  translation  engines. 


27 


4. 4. 4. 2  Interpretation  in  the  ER  Model 


Each  ER  attribute  has  a  domain.  This  domain’s  overlap  with  a  eorresponding  00  data 
type  is  of  interest  in  data/object  model  alignment.  Table  2  lists  the  types  of  domains  used 


in  the  EC2IEDM. 


Table  2.  LC2IEDM  Atomic  Domains 


Type 

Description 

NUMBER(n) 

An  integer  of  n  decimal  digits. 

NUMBER(15) 

An  integer  of  15  digits.  This  domain  is  used  throughout  the  LC21EDM  to 
record  entity  identifiers,  such  as  OBJECT-ITEM-ID  and  REPORTING-DATA-ID. 

NUMBER(m,n) 

A  floating-point  value  of  m  decimal  digits  with  precision  n. 

CHAR(6) 

A  string  of  exactly  6  characters.  This  domain  is  used  to  represent  values 
in  enumerated  domains.  In  the  LC21EDM,  any  attribute  whose  name 
ends  with  -CODE  (e.g.,  FACILITY-CATEGORY-CODE)  has  an  enumerated  do¬ 
main. 

VARCHAR(n) 

A  string  of  up  to  n  characters.  This  domain  is  typically  used  to  record  de¬ 
scriptive  text,  either  in  phrases  (where  n  is  fairly  small)  or  large  text 
blocks  (where  n  may  be  as  large  as  2000). 

4. 4. 4. 3  Interpretation  in  the  00  Model 


Eaeh  00  attribute  (or  JSIMS  EOM  field,  or  TCDM  EAC),  has  a  data  type.  This  data 
type,  whieh  is  always  atomie,  is  of  interest  in  data/object  model  alignment.  Table  3  lists 
the  atomie  data  types  used  in  the  JSIMS  EOM.  Table  4  lists  the  atomie  data  types  used  in 
the  TCDM. 


Table  3.  JSIMS  FOM  Atomic  Data  Types 


Type 

Description 

boolean 

A  4-byte  integer.  An  instance  of  the  type  may  have  a  value  of  either  0  or  1, 
corresponding  to  the  logical  values  false  and  true. 

char 

Not  really  a  domain,  but  instead  indicates  a  placeholder  for  future  capabili¬ 
ties. 

double 

An  8-byte  IEEE  double-precision  floating-point  number.  Its  range  is  ±210^3, 
and  it  has  about  17  significant  decimal  digits. 

float 

A  4-byte  IEEE  single-precision  floating-point  number.  Its  range  is  ±2127^  and 
it  has  about  7  significant  decimal  digits. 

long 

A  4-byte  integer  in  two's  complement  notation,  meaning  it  can  represent 
values  from  -2®^  to  2®^  -1. 

octet 

A  placeholder  for  buffer  data  when  shuttling  values  around  a  FOM  in  the 
HLA. 

string 

A  string  of  up  to  2®^  - 1  characters  (although  the  length  of  an  instance  is 
fixed). 

unsigned  long 

A  4-byte  integer,  values  of  which  can  range  from  0  to  2®^  - 1 . 
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Table  4.  TCDM  Atomic  Types 


Type 

Description 

ENUM 

An  enumerated  type,  with  a  list  of  literals. 

FLOAT32 

Equivalent  to  the  JSIMS  FOM  float  type. 

FLOAT64 

Equivalent  to  the  JSIMS  FOM  double  type. 

INT16 

A  two-byte  integer  in  two's  complement  notation,  meaning  it  can  repre¬ 
sent  values  from  -  2^®  to  2^®  -1 . 

INT32 

Equivalent  to  the  JSIMS  FOM  long  type. 

INT8 

A  one-byte  integer  in  two's  complement  notation,  meaning  it  can  repre¬ 
sent  values  from  -  2^  to 2^  - 1 . 

LEX_STRING 

Equivalent  to  the  JSIMS  FOM  string  type. 

STRING 

Equivalent  to  the  JSIMS  FOM  string  type;  differs  from  LEX  STRING  in 
implementation  characteristics  that  are  not  relevant  here. 

UINT16 

An  unsigned  two-byte  integer,  meaning  it  can  represent  values  from  0 
to  2^®  -1. 

UINT32 

An  unsigned  four-byte  integer,  meaning  it  can  represent  values  from  0 
to  2^2 

UINT8 

An  unsigned  one-byte  integer,  meaning  it  can  represent  values  from  0 
to  2®  -1. 

4. 4. 4. 4  Meaning  of  Alignment 

In  theory,  full  alignment  between  two  domains  requires  both  to  have  exactly  the  same 
data  type  and  domain.  It  must  be  possible  to  represent  exactly  the  same  values,  to  the 
same  degree  of  precision.  If  one  model  represents  distances  precise  to  millimeters,  then 
so  must  the  other  model — no  more  and  no  less. 

In  practice,  it  is  not  necessary  to  be  so  stringent.  One  model  might  not  need  all  the  preci¬ 
sion  of  which  the  other  is  capable.  Assessors  can  make  assumptions  about  what  a  simula¬ 
tion  or  C2  organization  might  reasonably  model,  and  these  assumptions  often  translate 
into  relaxed  exactness  requirements.  For  example: 

•  The  JSIMS  FOM  represents  coordinates  using  type  double,  whereas  the  LC2IEDM 
represents  them  using  a  NUMBER  with  various  magnitudes  (NUMBER(9,6)  for  lati¬ 
tudes;  NUMBER(10,6)  for  longitudes;  NUMBER(12,3)  for  elevations).  A  double  models 
both  greater  magnitude  and  greater  precision  than  the  LC2IEDM  domains.  How¬ 
ever,  the  EC2IEDM  represents  coordinates  in  degrees.  A  latitude  is  bounded  by 
±90;  a  longitude  by  ±180;  and,  until  wars  use  technology  located  twice  as  far  as 
the  moon,  NUMBER(12,3)  will  suffice  for  elevations.  Also,  the  LC2IEDM  can  repre¬ 
sent  position  to  within  1 1  cm.  This  is  precise  enough  for  simulations. 

•  The  JSIMS  EOM  represents  object  identifiers  using  a  string,  whereas  the 
EC2IEDM  represents  them  using  NUMBER(15).  A  string  contains  up  to  2^'  -1  char¬ 
acters,  obviously  a  larger  domain  than  a  15-digit  integer  can  model.  But  the  like¬ 
lihood  of  a  simulation  or  C2  system  modeling  even  lO'^  unique  objects  is  small. 

Two  domains  are  considered  fully  aligned  if  an  assessor  can  define  a  1:1  mapping  be¬ 
tween  them.  They  do  not  have  to  contain  the  same  elements.  Eor  example: 


29 


•  A  JSIMS  FOM  or  TCDM  enumerated  type  ean  align  to  an  LC2IEDM  enumerated 
domain,  even  though  they  eontain  different  literals.  An  example  is  the  alignment 
between  the  TCDM  EAC  Mine  Type  Category,  whose  domain  is  an  enumeration  of 
twelve  values,  and  the  EC2IEDM’s  MINEFIELD-PURPOSE-CODE  attribute,  whose 
domain  is  an  enumeration  of  seven  values.  Only  two  of  the  twelve  Mine  Type 
Category  values  map  to  EC2IEDM  values,  as  shown  in  Table  5.  That  TCDM  and 
the  EC2IEDM  do  not  use  the  same  literals  is  aceeptable  for  the  purposes  of 
alignment. 

•  A  JSIMS  EOM  eoordinate,  whieh  is  expressed  in  one  of  four  models — round- 
earth,  earth-eentered  inertial,  earth-eentered  rotational,  or  WGS-84  ellipsoidal — 
ean  align  to  an  EC2IEDM  eoordinate,  whieh  is  always  expressed  using  the  WGS- 
84  ellipsoidal  model. 

•  An  enumerated  domain  ean  align  to  a  string  domain.  Eor  example,  the  JSIMS 
EOM  attribute  movejype,  whose  domain  is  an  enumeration  of  six  values  (sueh  as 
groundjinear  and  great_circle)  aligns  to  the  EC2IEDM  attribute  ACTION-NAME,  whose 
domain  is  a  50-oharaoter  string.  One  strategy  for  implementing  this  alignment  is 
to  map  the  literal  values  from  the  TCDM  data  type  to  their  string  representation, 
storing  those  representations  in  ACTION-NAME. 

Table  5.  Example  of  Mapping  Enumeration  Literals 


TCDM  Value 

LC2IEDM  Value 

Unknown 

NKN 

Phony  /  Decoy 

PHONEY 

Degree  of  alignment  is  a  function  of  the  percentage  of  values  that  overlap.  Consider  an 
EC2IEDM  domain  C  and  JSIMS  EOM  domain  J.  The  following  situations  are  possible: 

•  L  and  J  can  map  1 : 1 ,  in  which  case  the  degree  of  alignment  is  1 00%. 

•  L  can  be  a  proper  subset  of  J,  or  vice-versa. 

•  L  and  J  can  have  a  non-empty  intersection  and  a  non-empty  disjunction. 

•  L  and  J  can  be  disjoint,  in  which  case  the  degree  of  alignment  is  0%. 

The  general  rule  is  that  the  degree  of  alignment  of  L  and  J  is  |C  n  j|/|C  u  j| ,  the  cardinal¬ 
ity  of  the  intersection  of  the  two  domains  divided  by  the  cardinality  of  the  union.  Degree 
of  alignment  is  a  value  between  0  and  1,  with  1  being  perfect  alignment  and  0  being  no 
alignment. 

Assessors  may  wish  to  adapt  this  rule  based  on  domain-specific  knowledge.  Eor  example, 
frequency  analysis  may  reveal  that  certain  values  in  one  model  are  more  likely  to  occur 
and  hence  are  more  important,  in  the  sense  that  interoperability  would  suffer  if  these  val¬ 
ues  could  not  be  expressed  in  the  other  model.  The  formula  for  calculating  degree  of 
alignment  could  be  tailored  based  on  such  knowledge.  As  another  example,  the  JSIMS 
EOM  and  the  EC2IEDM  both  contain  enumerated  domains  with  values  such  as  “un¬ 
known”  and  “not  otherwise  specified”,  and  sometimes  these  values  are  the  only  ones  in  a 
domain  that  align.  In  a  situation  where  unknown  data  equates  to  failure,  it  would  be  ap¬ 
propriate  to  remove  “unknown”  from  consideration  in  Value-level  alignment  analysis. 
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Appendix  E  gives  the  rules  for  eomputing  the  degree  of  alignment  between  a  JSIMS 
FOM  domain  and  an  LC2IEDM  domain,  based  on  the  type  of  domains  being  aligned. 
The  rules  in  the  appendix  systematize  the  eomputation  of  degree  of  alignment,  removing 
assessor  bias,  opinion,  and  interpretation.  Therefore,  the  eomputed  values  at  higher 
alignment  levels  also  have  unambiguous  semanties. 

4.5  Summary  of  Differences  from  the  AICDM/OMSC  Study 

Data/objeet  model  alignment  is  a  new  field  of  study.  It  may  be  helpful  to  explieitly  state 
how  its  definition  has  evolved  since  the  AICDM/OMSC  study  [IDA  2001]. 

4.5.1  Inheritance 

Inheritance  is  an  important  feature  in  00  modeling.  The  OMSC  makes  minimal  use  of 
inheritance  in  its  standard  objects,  instead  anticipating  that  M&S  developers  will  create 
subclasses  that  inherit  from  predefined  OMSC  classes.  The  JSIMS  FOM  and  the  TCDM 
have  extensive  inheritance  in  their  class  hierarchies,  so  the  EC2IEDM/WARSIM  assess¬ 
ment  was  IDA’s  first  opportunity  to  study  how  inheritance  affects  data/object  model 
alignment. 

Inheritance  requires  extra  study  from  assessors.  Section  4.4.3  discussed  how  assessors 
must  consider  all  State-level  assessments  derived  from  an  Entity-level  element  in  order  to 
avoid  using  an  attribute  for  multiple  purposes.  Inheritance  adds  an  extra  dimension  to  this 
consideration.  Assessors  performing  State-level  assessments  must  consider  not  only  the 
Entity-level  element  containing  the  attribute  but  its  ancestor  classes  (JSIMS  FOM)  or  en¬ 
tities  (EC2IEDM). 

Inheritance  affects  degree  of  alignment.  An  instance  of  an  Entity-level  element  implies 
the  existence  of  instances  of  its  ancestors.  In  other  words,  if  the  ancestors  do  not  align 
fully,  the  element  itself  won’t  align  fully  either. 

4.5.2  Value-Level  Alignment  Assessments 

IDA  developed  the  principles  for  Value-level  assessments  as  part  of  the  original  model  of 
data/object  model  alignment.  The  OMSC  seldom  has  enough  detail  to  make  Value-level 
assessments  feasible.  The  EC2IEDM/WARSIM  assessment  was  our  first  chance  to  gain 
extensive  experience  with  Value-level  assessments. 

Value-level  assessment  is  supposed  to  entail  rigorous  analysis  and  yield  repeatable  re¬ 
sults.  IDA  decided  to  create  a  set  of  rules  for  describing  the  alignment  between  two  do¬ 
mains.  These  rules  are  listed  in  Appendix  E.  The  degree  to  which  these  rules  are  general- 
purpose  or  study-specific  remains  to  be  seen. 

4.5.3  Aligning  Complex  Data  Types 

The  original  definition  of  alignment  recognized  that  the  focus  of  a  State-level  assessment 
may  involve  elements  from  higher  levels.  The  OMSC  does  not  specifically  state  the  pa¬ 
rameters  or  return  types  of  methods,  but  it  was  apparent  that  some  methods  would  use  or 
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return  abstractions.  The  AICDM/OMSC  study  handled  this  by  assuming  that  the  align¬ 
ment  of  a  method  related  to  the  alignment  of  the  concepts  it  referenced. 

The  JSIMS  FOM,  being  a  concrete  model,  provided  us  opportunities  to  work  with  State- 
level  elements  (attributes)  that  were  composites.  Our  assumption  that  a  composite  ele¬ 
ment  should  relate  to  a  concept  turned  out  to  be  unworkable.  The  composite  element  has 
a  relation  not  to  a  Conceptual-level  assessment  but  to  an  Entity-level  assessment. 

4.5.4  Entity-Level  Assessment  Adjustments 

The  previous  definition  of  alignment  at  the  entity  level  [IDA  2001]  provided  a  method  of 
calculating  the  alignment  of  a  model  with  an  entity  based  solely  on  the  values  of  the 
alignments  with  the  entity’s  attributes.  Flowever,  in  this  study,  many  WARSIM  classes 
were  discovered  to  align  well  at  the  attribute  level  although  the  semantics  of  the  class  it¬ 
self  was  not  precisely  discriminated  by  the  LC2IEDM  model.  This  situation  indicated  a 
need  to  adjust  the  calculated  or  “rolled-up”  assessment  of  a  class  (or  entity)  by  some  fac¬ 
tor  to  include  the  alignment  of  the  semantics  of  the  class/entity  itself  in  addition  to  the 
alignment  of  its  attributes. 

One  general  type  of  this  sort  of  problem  occurs  when  a  particular  WARSIM  class  does 
not  have  an  exact  counterpart  in  the  EC2IEDM,  although  a  more  general  entity  (or  super¬ 
type)  may  accommodate  the  data  involved.  Many  examples  of  this  type  were  found  when 
assessing  the  TCDM  terrain  classes  (e.g..  Amusement  Park)  used  by  WARSIM.  Many  such 
classes  in  the  TCDM  could  be  mapped  into  either  the  FEATURE  or  FACILITY  entities  of  the 
EC2IEDM,  and  their  types  could  be  recorded  in  the  OBJECT-TYPE-NAME  attribute.  But, 
there  is  no  standard  code  or  entity  in  the  LC2IEDM  that  is  specific  to  these  problem 
classes.  Hence,  the  LC2IEDM  itself  provides  no  standard  means  of  representing  such 
classes,  and  different  systems  could  map  the  same  type  of  feature  or  facility  into  different 
object  names.  Thus,  in  such  cases,  the  definition  of  data/object  model  alignment  is  quali¬ 
fied  so  that  a  lower  degree  of  Entity-level  alignment  can  be  assigned,  reflecting  the  ab¬ 
sence  of  a  standard  means  of  representing  a  class. 

4. 5. 4.1  Generic  Model  Mapping  Examples 

To  motivate  this  qualification  of  our  definition  of  data/object  model  alignment,  it  may  be 


Figure  10.  Mapping  the  LC2IEDM  to  a  Very  Simple  Model 
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instructive  to  consider  some  very  “high-level”  models  that  are  capable  of  representing 
practically  anything.  Perhaps  the  simplest  such  relational  model  (call  it  MODEL_l)  is  one 
with  a  single  entity  (call  it  ENTITY_1)  and  a  single  data  attribute  (call  it  data_l).  If  data_l  is 
a  variable  length  character  string  of  sufficiently  great  length,  it  could  accommodate  all  of 
the  data  of  any  database  model  such  as  the  LC2IEDM  as  illustrated  in  Figure  10.^  Any 
such  data  could  be  added,  updated,  and  deleted  (albeit  with  some  difficulty)  provided  that 
suitable  formatting  conventions  and  translation  rules  were  formulated  to  specify  where 
different  data  elements  from  the  other  model  could  be  found  in  this  monstrous  data 
string.^  While  any  data  model  whatsoever  could  be  mapped  into  this  simple  model,  we 
would  not  consider  this  model  well-aligned  with  any  real-world  data  model  of  any  com¬ 
plexity. 

Another  example  of  a  simple  generic  model  which  could  accommodate  virtually  any 
other  data  model  is  illustrated  in  Figure  11.  This  model  includes  separate  entities  for  ob¬ 
jects,  their  attributes  and  relations,  although  it  is  not  specific  about  any  particular  kinds  of 
such  data  elements. 
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Figure  11.  A  more  structured  general  model  (in  IDEFIX) 


Part  of  the  reason  that  generie  models  like  those  just  illustrated  eannot  be  eonsidered 
well-aligned  with  more  eomplex  models  is  that  they  provide  no  standard  means  of  repre¬ 
senting  speeifie  data  elements  sueh  as  may  be  found  in  ordinary  models.  There  are  no  en¬ 
tities  or  attributes  whieh  distinguish  any  speeifie  type  of  data.  In  partieular,  there  is  no 
standard  means  of  distinguishing  entities  sueh  as  the  five  battlefield  entities  of  the 


^  The  illustration  of  the  LC2IEDM  in  this  figure  is  a  greatly  reduced  copy  of  the  main  view  of  all 
LC2IEDM  classes  where  each  tiny  box  represents  an  entity  and  the  lines  between  them  are  relations. 

’  For  example,  an  XML  representation  of  the  LC2IEDM  model  could  be  used  as  the  value  of  the  data_l 
attribute. 
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LC2IEDM  -  FACILITY,  FEATURE,  MATERIEL,  ORGANISATION,  and  PERSON  -  much  less  their 
many  attributes  and  relations.  Translation  rules  may  be  defined  to  map  other  models  into 
sueh  generie  models,  but  those  rules  are  not  part  of  the  generie  models  themselves. 

4. 5. 4. 2  Definitions  and  Principles  for  Non-Standard  Mappings 

To  clarify  our  intuitions  here,  we  define  the  key  eoneept  as  follows: 

A  model  M  has  a  standard  means  of  representing  a  data  element  E  from  model 
M'  if  and  only  if  M  has  a  representation  R  (composed  only  of  its  predefined  enti¬ 
ties/classes,  attributes,  coded  values,  and/or  relationships/associations)  which  ex¬ 
plicitly  captures  just  (all  and  only)  the  same  type  of  information  as  E. 

When  a  model  has  no  standard  means  of  representing  a  data  element,  different  users  are 
free  to  represent  its  data  in  different  ways.  While  this  ean  be  aeeep table  if  one’s  only  eon- 
eern  is  aeeommodating  data,  it  does  not  faeilitate  exehange  of  data  amongst  systems. 
Having  different  systems  plaeing  data  into  a  database  using  different  eneoding  sehemes 
does  not  promote  data  interoperability.  In  sueh  eases,  the  data  model  itself  provides  no 
guidanee  on  where  to  find  partieular  types  of  data,  as  sueh  eneoding  sehemes  are  not  part 
of  the  model.  Sinee  the  purpose  of  our  definition  of  data/objeet  model  alignment  is  to 
provide  a  measure  of  data  interoperability  of  models,  models  with  no  standard  means  of 
representing  eertain  types  of  data  eannot  be  eonsidered  well  aligned  with  the  elements 
that  distinguish  that  type  of  data  in  other  models. 

The  general  prineiple  we  abstraet  from  this  and  other  examples  like  it  is  this: 

If  a  data  element  E  from  a  model  M  has  no  standard  representations  in  a  model 
M‘ ,  then  M‘  has  a  lower  degree  of  alignment  with  element  E  from  M,  other  things 
being  equal,  than  a  model  which  does  have  a  standard  representation  defined 
for  element  E. 

This  principle,  which  may  be  more  obvious  in  the  extreme  ease  of  MODEL_l  (eompared  to 
WARSIM)  applies  equally  in  less  extreme  eomparisons.  Aetual  examples  where  this  prin¬ 
eiple  applies  abound  in  the  data/objeet  model  alignment  between  WARSIM  and  the 
LC2IEDM.  We  have  already  noted  that  the  Environment  area  of  WARSIM  eontains  many 
elasses  (e.g..  Amusement  Park)  from  the  TCDM  that  laek  a  standard  representation  in  the 
EC2IEDM.  Sueh  terrain  elasses  may  be  distinguished  by  inserting  a  name  for  them  in  the 
OBJECT-TYPE-NAME  field  of  the  EC2IEDM  OBJECT-TYPE  entity,  but  there  is  no  standard 
way  to  identify  them,  so  different  sourees  might  use  different  names  to  represent  the  same 
environmental  feature  or  the  same  name  for  different  features.  Sinee  the  EC2IEDM  itself 
provides  no  standard  for  distinguishing  sueh  elasses,  it  is  less  well  aligned  with  these 
elasses  that  other  environmental  elasses  (e.g.,  “Built  up  area”)  whieh  have  an  explieit  eode 
(e.g.,  BUA)  in  the  EC2IEDM  to  distinguish  them. 

Although  nonstandard  representations  align  less  well  than  standard  representations,  they 
do  provide  a  means  to  represent  data,  and  deserve  some  lesser  degree  of  alignment.  A 
model  that  ean  somehow  represent  data  is  at  least  eapable  of  allowing  interoperation  (our 
ultimate  interest),  whereas  one  that  eannot  capture  the  data  of  interest  does  not  even  al¬ 
low  exehange  of  that  data. 
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The  general  prineiples  just  explained  provide  some  guidance  on  assessing  the  alignment 
of  data  elements  with  no  standard  representations,  but  do  not  prescribe  a  method  for 
computing  such  alignment  values.  To  motivate  our  approach  to  computing  alignment  as¬ 
sessment  values  in  such  cases,  it  should  help  to  examine  additional  cases.  Consider  the 
TCDM  classes  Anchorage  and  Pier/Wharf/Quay,  each  of  which  maps  to  the  FACILITY  entity 
with  the  associated  FACILITY-TYPE-CATEGORY-CODE  =  HARBUR,  which  is  displayed  as 
“Harbour”  (see  Figure  12).  The  problem  with  this  alignment,  of  course,  is  that  the 
LC2IEDM  model  itself  provides  no  standard  means  of  distinguishing  an  anchorage  from 
a  pier/wharFquay.  But,  compare  this  to  the  situation  for  the  TCDM  class  Amusement  Park. 
There  is  no  code  in  the  LC2IEDM  that  is  even  close  to  representing  this  environmental 
entity,  so  the  best  that  can  be  done  is  to  use  the  FACILITY-TYPE-CATEGORY-CODE  =  NOS  for 
“not  otherwise  specified”.  However,  22  classes  from  the  TCDM  are  in  a  similar  situation 
and  map  to  FACILITY-TYPE  =  NOS.  Thus,  this  EC2IEDM  representation  is  much  less  dis¬ 
criminating  than  that  for  Anchorage.  An  anchorage  from  WARSIM  is  identified  more  spe¬ 
cifically  as  a  harbour,  while  an  amusement  park  can  only  be  specified  as  one  of  22  un¬ 
specified  types  of  facilities  in  the  EC2IEDM.  Hence,  the  EC2IEDM  provides  a  closer  ap¬ 
proximation  for  an  anchorage  than  for  an  amusement  park.  It  is  appropriate  to  assign  a 
lower  degree  of  alignment  to  the  EC2IEDM’s  alignment  with  Amusement  Park  than  that  for 
Anchorage  (other  things  being  equal). 
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Figure  12.  Non-standard  Mappings  from  the  TCDM  to  the  LC2IEDM 

This  example,  and  others  like  it,  suggest  an  additional  guideline  for  computing  degrees  of 
alignment  of  non-standard  mappings: 

If  two  data  elements  Ei  and  E2  from  a  model  Mhave  no  standard  representations 
in  a  model  M',  but  Ei  has  a  more  specific  mapping  to  M'  than  E2  does,  then  the 
degree  of  alignment  of  Fi  is  greater  than  that  of  E2,  other  things  being  equal. 

The  concept  of  specificity  used  here  is  an  abstraction  of  the  situation  in  the  example 
wherein  the  EC2IEDM  has  a  more  specific  representation  (HARBUR)  for  a  WARSIM  an¬ 
chorage  than  its  representation  (NOS)  for  an  amusement  park.  There  are  different  ways 
such  a  concept  of  specificity  might  be  defined.  We  have  elected  to  use  a  definition  that 
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allows  a  complete  ordering  of  speoifieity  relative  to  any  two  models  whose  alignment  is 
being  assessed.  This  is: 

A  mapping  from  a  data  element  E]  in  model  M  to  a  model  M'  is  more  specific 
than  a  non-standard  mapping  of  Ei  from  M  to  M'  if  there  is  a  smaller  number  (m) 
of  data  elements  from  Mi  that  map  into  the  same  standard  parts  of  a  representa¬ 
tion  (Ri)  of  El  in  M'  than  the  number  (n)  that  map  from  E2  into  a  standard  repre¬ 
sentation  (R2)  vaM' . 

This  is  illustrated  in  Figure  13  where  the  elements  Ei  and  £'2  in  model  M  may  be  any  en- 
tity/elass,  attribute,  eoded  value,  or  relationship,  while  the  representations  Rj  and  R2  in 
model  M'  are  those  entities/elasses  attributes,  relations  and  eoded  values  of  M'  that  are 
required  to  represent  E\  and  E2,  respeetively.  Elements  Eu  to  Eim  in  the  figure  illustrate 
all  the  other  elements  in  model  M  whieh  map  into  the  same  representation,  as  does  Ei, 
while  elements  E'21  to  E'2n  illustrate  those  elements  whieh  map  into  R2.  Naturally,  m  eould 
be  zero,  while  n  must  always  be  greater  than  zero  when  the  Ei  mapping  is  more  speeifie 
than  that  of  E2. 

If  m<n  then  has  a  more  specific  mapping  than  E2  from  M  to  /W'. 
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Figure  13.  Definition  of  More  Specific  Mapping  Between  Models 


Since  only  two  TCDM  classes  have  the  same  mapping  to  standard  LC2IEDM  elements 
representing  an  anehorage,  the  anehorage  elass  in  the  TCDM  has  a  more  speeifie  map¬ 
ping  to  the  EC2IEDM  than  does  the  amusement  park  elass,  whose  standard  representa¬ 
tion  eannot  distinguish  twenty-two  different  TCDM  elasses.  While  any  of  these  entities 
may  be  diseriminated  in  the  EC2IEDM  by  assigning  a  distinetive  name  in  the  OBJECT- 
TYPE-NAME  attribute  (as  in  Eigure  12),  sueh  speeifie  names  eould  be  eomposed  in  any 
manner  and  are  not  standard  parts  of  the  EC2IEDM. 
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4. 5. 4. 3  Calculating  Alignment  Values  for  Non-standard  Mappings 

The  principles  derived  from  our  examples  provide  a  basis  for  ordering  non-standard 
alignments  but  still  under-constrain  the  possible  assignment  of  specific  degrees  of  align¬ 
ment.  While  it  is  clear  that  a  standard  alignment  should  have  a  higher  degree  of  alignment 
than  a  non-standard  one,  and  that  a  more  specific  alignment  should  have  a  higher  degree 
of  alignment  than  a  less  specific  one  (ceteris  paribus),  many  options  are  open  as  to  how  to 
assign  actual  degrees  of  alignment.  The  approach  we  have  taken  assigns  a  certain  amount 
of  credit  for  the  minimal  capability  of  having  some  means  of  accommodating  a  data  ele¬ 
ment.  That  is,  credit  is  given  for  having  a  distinguishable  means  of  representing  data  even 
if  it  is  non-standard  to  the  model.  But,  any  choice  of  how  much  credit  to  assign  for  this 
minimal  capability  is  bound  to  be  somewhat  arbitrary.  For  our  assessments,  we  assign 
50%  of  the  credit  for  this  minimal  degree  of  alignment. 

The  rest  of  the  credit  for  alignment  we  determine  on  a  linear  scale  based  on  the  specific¬ 
ity  of  the  mapping.  If  there  is  a  one-to-one  mapping  from  one  model  to  another,  then  data 
can  be  moved  from  one  model  to  the  other  and  back  with  no  loss  of  information,  just  us¬ 
ing  the  definitions  of  the  two  models.  Hence,  we  give  the  full  balance  of  50%,  yielding  a 
total  of  100%  alignment  when  there  is  a  one-to-one  mapping  from  an  entity  in  one  model 
to  a  standard  representation  in  the  other  that  covers  it.  But  when  multiple  data  elements 
map  into  the  same  representation,  we  divide  the  balance  of  50%  by  the  number  of  such 
duplicate  elements.  Thus,  the  assessment  of  a  non-standard  mapping  from  a  class  (as  dis¬ 
tinguished  by  its  definition)  in  the  WARSIM  models  to  the  LC21EDM  is  calculated  by  the 
formula: 

Credit  =  (50%  -l-  (50%  h-  (number  of  indistinguishable  classes)) 

Applying  this  to  the  Anchorage  class,  we  get  a  credit  of  (50%  +  (50%  -h  2))  =  75%,  while 
the  Amusement  Park  class  gets  a  credit  of  (50%  +  (50%  -h  22))  =  52%.  This  credit  is  re¬ 
ferred  to  as  an  adjustment  factor  in  the  entity  level  assessment  window  found  in  the  ac¬ 
companying  alignment  database. 

But  this  is  just  one  part  of  full  assessment  of  a  class’  degree  of  alignment.  The  alignment 
of  a  class  or  entity  also  depends  upon  its  attributes  (both  immediate  and  inherited) — 
hence  the  need  for  the  ceteris  paribus  conditions  cited  in  the  assessment  principles  above. 
So,  for  the  full  entity-level  assessment  of  a  class,  we  use  this  credit  from  the  class  defini¬ 
tion  mapping  as  a  multiplicative  factor  to  adjust  the  assessment  based  on  the  average  as¬ 
sessed  values  of  all  of  the  class’  attributes,  yielding  the  equation: 

Assessment(Class)  =  Credit  x  (average  of  attribute  assessments) 

This  enables  the  assessment  of  a  class  alignment  to  reflect  the  extent  to  which  that  class  is 
clearly  distinguished  in  the  aligned  model,  as  well  as  the  extent  to  which  its  attributes  are 
modeled.  This  formulation  is  somewhat  arbitrary,  although  it  is  designed  to  uniformly 
reduce  the  credit  for  having  attributes  aligned  in  proportion  to  how  well  a  model  can  dis¬ 
tinguish  what  they  are  attributes  of. 
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4.5.5  Structural  Alignment 

If  an  ER  model  and  an  00  model  exhibit  State-level  alignment  by  virtue  of  a  struetural 
element — relationships  between  entities  in  the  ER  model,  and  subelass  relationships  in 
the  00  model — there  is  structural  alignment.  Struetural  alignment  means  that  one  of  the 
models  has  an  attribute  that  aligns  at  the  State  level  through  elements  other  than  attributes 
of  the  other  model.  Typieally,  an  assessor  identifies  the  need  for  struetural  alignment 
when  performing  State-level  alignment  analysis,  then  sorts  out  the  details  during  Value- 
level  alignment  analysis. 

Consider  the  problem  of  determining  the  JSIMS  EOM  elements  that  are  aligned  with  the 
EC2IEDM  attribute  EQUIPMENT-TYPE-CATEGORY-CODE.  This  attribute  breaks  down 
equipment  types  into  3 1  eategories  sueh  as  “Aireraft,  fixed  wing”  and  “Eleetronies,  C3I”. 
Any  EC2IEDM  representation  of  a  materiel  item  may  have  an  assoeiated  instanee  of 
EQUIPMENT-TYPE,  and  the  value  of  EQUIPMENT-TYPE-CATEGORY-CODE  helps  deseribe  that 
item. 

Eike  the  EC2IEDM,  the  JSIMS  EOM  elass  strueture  models  both  instanees  and  types. 
Types  are  modeled  as  subelasses  of  elass  abstract.  That  elass  is  an  abstraet  elass,  i.e.,  only 
its  subelasses  ean  be  instantiated.  Therefore,  any  alignment  of  the  EQUIPMENT-TYPE  entity 
must  be  to  a  subelass  of  abstract.  The  speeifie  subelass  will  be  determined  by  the  value  of 
EQUIPMENT-TYPE-CATEGORY-CODE.  In  other  words,  EQUIPMENT-TYPE-CATEGORY-CODE 
aligns  strueturally. 

There  is  no  struetural  alignment  of  the  EC2IEDM  with  respeet  to  a  JSIMS  EOM  attribute. 
This  is  a  modeling  decision.  Structural  alignment  between  a  JSIMS  EOM  attribute  and 
the  EC2IEDM  would  occur  when  a  JSIMS  EOM  attribute  aligns  with  respect  to  a  rela¬ 
tionship  between  two  EC2IEDM  entities.  This  situation  occurs  frequently.  However,  the 
EC2IEDM  tables  representing  entities  include  foreign  keys,  i.e.,  attributes  that  implement 
the  relationships.  We  found  it  more  convenient  to  align  JSIMS  EOM  attributes  to  these 
foreign  keys  than  to  relationships. 
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5.  Process  of  Alignment 


Section  4  defines  alignment  between  an  ER  model  and  an  00  model.  To  use  this  defini¬ 
tion  involves  following  a  process  for  alignment  assessment.  The  process  provides: 

•  Guidance  on  where  to  begin.  The  LC2IEDM  and  the  JSIMS  EOM  contain  hun¬ 
dreds  of  elements.  The  process  helps  assessors  choose  a  starting  point. 

•  Rules  for  completeness.  Assessors  need  to  know  whether  an  element  is  considered 
fully  assessed,  and  if  not,  what  work  remains  to  be  done. 

•  Methods  for  assessing  alignment.  Insofar  as  is  possible,  subjectivity  and  ambigu¬ 
ity  should  be  absent  from  an  alignment  assessment.  Thus,  when  assessing  the 
alignment  of  two  given  sets  of  elements,  it  is  helpful  for  assessors  to  have  a  set  of 
methods  to  follow. 

•  Rules  for  using  the  results  of  alignment  assessment.  Alignment  assessment  aims  to 
identify  changes  to  each  model  that  would  improve  alignment.  The  assigned  de¬ 
grees  of  alignment  can  help  identify  such  changes,  but  the  results  of  Value-level 
analysis  are  very  low-level  and  do  not  suggest  strategies  for  improvement. 

•  Guidance  on  documenting  results.  The  work  products  yielded  by  each  process 
step  leave  a  trail  that  makes  alignment  assessment  understandable  and  repeatable. 

This  section  presents  a  process  for  alignment  assessment,  specifically  that  used  in  the 
EC2IEDM/JSIMS  EOM  study.  It  covers  the  process  steps  and  the  methods  used  in  each 
step. 

5.1  An  Overview  of  the  Alignment  Assessment  Process 

The  process  is  based  on  top-down  analysis,  proceeding  through  the  four  alignment  levels. 
Eigure  14  shows  an  overview.  The  process  can  be  summarized  as  follows.  The  assessors 
divide  each  model  into  Concepts  and  analyze  each  Concept  for  alignment.  This  analysis 
entails: 

•  Identifying  Concepts  from  each  model  that  appear  to  align,  i.e.,  model  the  same 
information. 

•  Assigning  a  degree  of  alignment  between  the  identified  Concepts. 

•  “Drilling  down”  to  Entity-level  analysis  on  each  component  of  the  Concepts. 

Similarly,  Entity-level  analysis  entails  identifying  Entity-level  elements  from  each  model 
that  appear  to  align,  assigning  a  degree  of  alignment  between  identified  elements,  then 
drilling  down  to  State-level  analysis  for  each  attribute  of  the  element.  State-level  analysis 
consists  of  identifying  attributes  from  each  model  that  appear  to  align,  assigning  a  degree 
of  alignment  between  identified  attributes,  then  drilling  down  to  Value-level  analysis  for 
an  attribute’s  domain.  Value-level  analysis  consists  only  of  identifying  domains  and  as¬ 
signing  a  degree  of  alignment;  it  is  the  lowest  level,  so  there  is  no  drilling  down. 


39 


Level 


Process  Step 


Conceptual 


Entity 


Align  each  Concept 

A  r\ 

Align  each  Entity  of  each  Concept 


State  Align  each  Attribute  of  each  Entity 

A 


T 

Value  Align  each  Attribute’s  domain 


Legend 


I  Drill  down  (assign 
I  degree  of 
alignment) 


TRoll  up  (compute 
degree  of 
alignment) 


Figure  14.  High-Level  Depiction  of  Alignment  Assessment  Process 


The  results  of  Value-level  analysis  are  “rolled  up”  to  provide  the  State-level  computed 
degree  of  alignment.  The  State-level  computed  degrees  of  alignment  are  rolled  up  to  give 
the  Entity-level  computed  degree  of  alignment.  The  Entity-level  computed  degrees  of 
alignment  are  rolled  up  to  give  the  Conceptual-level  computed  degree  of  alignment. 


Note  the  use  of  the  phrase  “appear  to  align”  rather  than  “align”  in  all  levels  except  the 
Value  level.  By  the  definition  of  alignment  in  Section  4,  these  levels  concentrate  on  in¬ 
formation  that  has  certain  abstract  characteristics.  In  other  words,  it  is  not  possible  to  de¬ 
termine  alignment  with  absolute  certainty  at  these  levels;  the  necessary  information  is 
found  only  at  the  Value  level.  The  top  three  levels  serve  as  information  gathering  steps  to 
set  the  context  for  Value-level  degree  of  alignment  analysis. 


In  our  experience,  most  interesting  alignment  assessment  results  occur  during  State-  and 
Value-level  alignment  analysis.  This  fact  should  not  be  taken  to  mean  that  Conceptual- 
and  Entity-level  alignment  assessment  can  be  neglected.  The  two  steps  help  assessors 
gather  and  classify  the  information  needed  to  interpret  their  results. 


The  assessors  assign  a  degree  of  alignment  at  each  level.  At  the  Value  level,  the  degree  of 
alignment  is  a  quantitative  statement  of  alignment.  At  other  levels,  it  is  a  judgment.  It 
provides  some  guidance  as  to  where  a  particular  assessment  is  heading.  However,  the 
computed  degree  of  alignment  can  differ  (sometimes  greatly)  from  the  assigned  degree  of 
alignment.  Such  situations  typically  reflect  studies  between  the  time  the  degree  of  align¬ 
ment  was  assigned  and  when  it  was  computed. 


There  is  another  reason  to  assign  a  degree  of  alignment  at  levels  other  than  the  Value 
level.  Sometimes  an  assessor  cannot,  or  need  not,  drill  down.  This  can  happen  if: 

•  There  is  no  alignment,  i.e.,  an  attribute  in  one  model  has  no  counterpart  in  the 
other  model.  In  this  case  the  assessor  will  assign  a  0%  the  degree  of  alignment. 

•  There  is  some  ambiguity  that  makes  drilling  down  impossible.  This  typically  oc¬ 
curs  when  a  model  is  incomplete  or  improperly  defined.  The  assessor  usually  at¬ 
tempts  to  guess  what  the  model  should  contain  and  assigns  a  degree  of  alignment 
accordingly.  However,  the  assessor  should  not  drill  down  further. 
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•  An  attribute  is  not  modeled  but  has  an  invariant  value  in  the  context  of  the  as¬ 
sessment.  Consider  the  ORGANISATION-CATEGORY-CODE  attribute  of  LC2IEDM  en¬ 
tity  ORGANISATION.  This  attribute  has  five  possible  values:  UN  (unit),  PC  (post),  00 
(eonvoy),  NKN  (not  known),  and  NOS  (not  otherwise  specified).  An  attribute  is  al¬ 
ways  assessed  in  context  of  a  concept,  meaning  its  alignment  is  being  assessed 
with  regard  to  modeling  that  concept.  Now  consider  when  the  JSIMS  FOM  and 
the  LC2IEDM  are  being  aligned  with  respect  to  the  Unit  concept.  In  an 
EC2IEDM  model  of  a  unit,  ORGANISATION-CATEGORY-CODE  will  always  be  UN. 
Therefore,  ORGANISATION-CATEGORY-CODE  does  not  impede  alignment,  even 
though  the  JSIMS  FOM  has  no  attribute  that  models  the  value. 

That  an  attribute  has  an  invariant  value  in  context  is  discovered  during  State-level 
alignment  assessment.  The  assessor  assigns  a  degree  of  alignment  of  100%. 

•  An  attribute  aligns  structurally.  In  a  relational  model,  foreign  keys  define  rela¬ 
tionships  between  records.  In  an  object  model,  some  of  these  relationships  are 
captured  using  inheritance  and  composition.  Some  EC2IEDM  foreign  keys  have 
no  equivalent  attribute  in  the  JSIMS  FOM,  but  still  align  in  the  sense  that  the 
JSIMS  FOM  provides  an  inheritance  or  composition  relationship  that  achieves  the 
same  end. 

That  an  attribute  aligns  structurally  is  discovered  during  State-level  alignment  as¬ 
sessment.  The  degree  of  alignment  depends  upon  whether  the  structures  in  ques¬ 
tion  fully  model  the  structure  conveyed  by  the  attribute. 

In  these  cases,  the  assigned  degree  of  alignment  is  used  as  the  computed  degree  of  align¬ 
ment  for  the  assessment. 

5.2  The  Process  as  a  Template 

The  beginning  of  Section  5  mentioned  that  the  process  being  described  is  the  one  used  in 
the  FC2IEDM/WARSIM  alignment  assessment.  That  sentence  deserves  further  explana¬ 
tion.  The  process  described  below  is  similar,  but  not  identical  to,  the  one  used  in  the 
AICDM/OMSC  alignment  assessment.  It  differs  because: 

•  The  OMSC  is  not  a  complete  model.  In  the  AICDM/OMSC  study,  we  were  sel¬ 
dom  able  to  perform  Value-level  alignment  analyses;  we  usually  had  to  stop  with 
State-level  analyses.  In  the  FC2IEDM/WARSIM  study,  we  almost  always  drilled 
down  to  the  Value  level. 

•  The  OMSC  and  the  JSIMS  FOM  use  different  object  models.  As  a  result,  we  em¬ 
ployed  different  methods  to  assess  the  alignment  of  OMSC  elements  to  AICDM 
elements  than  we  used  to  assess  the  alignment  of  JSIMS  FOM  elements  to 
FC2IEDM  elements. 

In  fact,  we  expect  that  every  alignment  assessment  will  differ  from  its  predecessors.  As¬ 
sessors  will  follow  a  different  process  each  time,  based  on  factors  such  as  those  noted 
above. 

We  therefore  think  of  Figure  14  (above)  as  a  process  template.  We  expect  one  of  the  pre¬ 
liminary  steps  of  any  alignment  assessment  will  be  to  tailor  this  template  according  to  the 
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features  of  the  models  being  assessed.  Factors  to  consider  include  the  object  model  and 
the  completeness  of  each  model,  as  just  described,  as  well  as: 

•  Where  to  start — for  example,  whether  to  work  strictly  top-down. 

•  Methods  to  use  for  determining  which  elements  align  to  which. 

•  Methods  to  use  for  assigning  degree  of  alignment. 

•  Formulas  to  use  for  computing  degree  of  alignment. 

These  factors  influence  the  process  steps  and  methods  for  a  given  assessment.  It  is  our 
hope  that  our  work  will  lead  to  a  process  and  method  library  for  alignment  assessment. 
Future  assessors  would  select  the  process  that  most  closely  fits  their  needs,  tailor  it  as 
necessary,  and  (insofar  as  practical)  use  existing  methods  to  perform  their  work.  Like 
product  lines  ([CN  2001]),  the  implementation  of  an  alignment  assessment  process  tem¬ 
plate  could  save  substantial  effort. 

5.3  Alignment  Directionality 

Section  1  described  the  need  for  data/object  model  alignment  along  the  following  lines. 
Consider  an  ER  model  E  that  supports  C2  and  an  00  model  O  that  supports  M&S.  Given 
data  expressed  in  one  model,  when  that  data  are  converted  to  the  other  model  and  then 
back  again,  is  the  converted  data  equivalent  to  the  original? 

There  is  a  notion  of  directionality  in  the  last  sentence.  Either  the  ER  or  the  00  model  is  a 
starting  and  ending  point,  in  the  sense  that  an  assessor  verifies  alignment  against  elements 
of  one  model  or  the  other.  In  the  EC2IEDM/JSIMS  EOM  alignment  assessment,  there  are 
two  distinct  questions  to  answer: 

1.  Can  JSIMS  EOM  data  converted  to  the  EC2IEDM  be  re-converted  back  to  the 
JSIMS  EOM? 

2.  Can  EC2IEDM  data  converted  to  the  JSIMS  EOM  be  re-converted  back  to  the 
EC2IEDM? 

The  alignment  assessment  process,  then,  seeks  to  verify  alignment  with  respect  to  one 
model  or  the  other.  Section  4  and  Eigure  14  present  alignment  without  regard  to  direc¬ 
tionality.  However,  when  assessors  begin  studying  model  elements,  the  issue  of  verifica¬ 
tion  becomes  paramount,  and  it  is  necessary  to  choose  an  alignment  direction  when  fol¬ 
lowing  the  process.  (A  complete  study  of  alignment  should  assess  alignment  in  both  di¬ 
rections,  if  possible.) 

The  EC2IEDM/JSIMS  EOM  study  really  consists  of  two  separate  alignment  assessments. 
The  first  determines  the  degree  to  which  the  EC2IEDM  aligns  to  the  JSIMS  EOM.  The 
second  determines  the  degree  to  which  the  JSIMS  EOM  aligns  to  the  EC2IEDM.  Both 
assessments  share  certain  characteristics — such  as  the  process  in  Eigure  14 — ^but  differ  in 
process  and  method  details.  Eor  this  reason.  Section  5  covers  the  process  for  each  as¬ 
sessment  separately. 


42 


5.4  JSIMS  FOM-to-LC2IEDM  Assessment 


This  section  discusses  the  alignment  assessment  process  where  the  issue  is  the  degree  to 
which  the  LC2IEDM  aligns  to  the  JSIMS  FOM  (question  1  above).  It  covers  the  overall 
process  and,  for  each  level,  presents  the  methods  used  to  assign  a  degree  of  alignment 
and  the  formula  used  to  compute  a  degree  of  alignment. 

5.4,1  Process 

Figure  15  depicts  the  process  for  JSIMS  FOM-to-FC2IEDM  alignment  assessment.  A 
comparison  of  Figure  15  with  Figure  14  reveals  two  differences: 

1.  Figure  15  shows  alignment  directionality.  The  text  emphasizes  that  the  assessor 
aligns  FC2IEDM  elements  with  respect  to  JSIMS  FOM  elements. 

2.  Figure  15  contains  an  alternate  drill-down  path  from  State-level  assessment.  This 
path  leads  back  up  to  the  Entity  level,  where  it  enters  a  cycle  between  Entity-  and 
State-level  elements. 

The  alternate  path  is  necessary  because  some  JSIMS  FOM  attributes  have  data  types  that 
are  complex  data  types.  A  complex  data  type  is  a  collection  of  attributes.  It  is  semanti¬ 
cally  equivalent  to  a  class,  except  that  it  cannot  inherit  attributes  from  another  class.  Be¬ 
cause  classes  are  part  of  Entity-level  alignment  assessment,  it  follows  that  complex  data 
types  should  be  assessed  as  Entities.  The  general  rules  for  drilling  down  from  a  State- 
level  alignment  assessment  are  therefore: 


Level 


Process  Step 


Conceptual  For  each  JSIMS  FOM  package, 
align  LC2IEDM  views 


Entity  For  each  JSIMS  FOM 


For  a  JSIMS  FOM  complex 
data  type,  align  LC2IEDM 
entities 


class  in  a  package,  align 
LC2IEDM  entities 


State 


For  each  class  attribute, 
align  LC2IEDM  attributes 


For  each  complex  data 
type  attribute,  align 
LC2IEDM  attributes 


\ 


/\ 


▼  y  Drill  down  (assign  degree 

Value  Align  each  attribute’s  domain  y  of  alignment) 


i 


Roll  up  (compute  degree 
of  alignment) 


Figure  15.  JSIMS  FOM-to-LC2IEDM  Alignment  Process 
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•  If  assessing  an  attribute  whose  data  type  is  an  atomie  type  (i.e.,  not  a  complex 
data  type),  drill  down  to  the  Value  level. 

•  If  assessing  an  attribute  whose  data  type  is  a  complex  data  type,  perform  an  En¬ 
tity-level  alignment  assessment  of  the  complex  data  type,  and,  for  each  attribute 
of  that  type,  perform  a  State-level  alignment  assessment.  Compute  the  degree  of 
alignment  of  the  complex  data  type  using  a  formula  based  on  the  degrees  of 
alignment  of  all  the  complex  data  type’s  attributes.  Compute  the  degree  of  align¬ 
ment  of  the  original  class  attribute  as  the  computed  degree  of  alignment  of  the 
complex  data  type  that  is  the  attribute’s  data  type. 

Sometimes  a  complex  data  type  contains  attributes  whose  data  types  are  themselves  com¬ 
plex  data  types.  An  assessor  will  need  to  repeat  the  cycle  in  Figure  15  multiple  times  to 
complete  the  assessment.  Figure  16  shows  one  of  the  structures  from  the  JSIMS  FOM 
where  repeated  Entity-level  assessments  of  complex  data  types  are  necessary  to  resolve 
an  attribute.  Ultimately,  drilling  down  terminates  either  with  a  Value-level  assessment  (as 
shown  in  Figure  16)  or  with  a  higher-level  assessment  from  which  drilling  down  is  not 
possible. 

Figure  16  shows  assessment  nuances  worthy  of  discussion.  The  attributes  head  and  tail 
both  have  data  type  coordinate_3d_c,  which  represents  a  point  as  a  (latitude,  longitude,  ele¬ 
vation)  triple.  Because  head  and  tail  model  the  same  kind  of  information,  the  assessment  of 
coordinate_3d_c  is  valid  for  either  of  them.  In  other  words,  it  is  sometimes  possible  to  reuse 
alignment  assessments.  Once  an  analyst  has  drilled  down  from  head,  there  is  no  need  to 
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Figure  16.  Deep  Nesting  in  JSIMS  Complex  Data  Types 
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drill  down  from  tail. 


Figure  16  also  shows  a  circumstance  where  an  assessment  cannot  be  reused.  The  attrib¬ 
utes  elevation,  latitude,  and  longitude  are  all  of  type  double.  But  despite  their  common  use  of  a 
data  type,  they  do  not  model  the  same  kind  of  information.  A  latitude’s  domain  is 
bounded  by  ±90.  A  longitude’s  domain  is  bounded  by  ±180.  An  elevation’s  domain, 
which  is  measured  in  meters,  will  be  between  about  -100  and  4000  for  land-based  opera¬ 
tions.  An  alignment  of  double  shared  by  the  three  attributes  would  overlook  their  necessar¬ 
ily  different  ranges. 

5.4.2  Level-Specific  Details 

The  following  subsections  cover  the  methods,  formulas,  and  heuristics  used  during  each 
alignment  assessment  level.  The  intent  is  to  show  the  difference  types  of  analysis  that  oc¬ 
cur  at  different  levels. 

The  material  is  presented  as  a  rational  process,  i.e.,  an  idealized  description  rather  than  a 
precise  depiction  of  reality  [PC  1986].  A  rational  process  is  easier  to  understand  and  fol¬ 
low  than  the  chaos  of  a  real  process.  It  can  also  be  summarized  more  concisely. 

5.4.2. 1  Conceptual  Level 

Alignment  assessment  at  the  Conceptual  level  is  concerned  with  revealing  the  degree  to 
which  the  highest-level  abstractions  of  the  models  align.  The  previous  alignment  study 
used  an  M&S  model  with  “standard  objects”,  which  were  a  set  of  classes  related  by  ag¬ 
gregation  and  inheritance.  In  that  study,  standard  objects  were  the  focus  of  Conceptual- 
level  alignment. 

In  the  JSIMS  FOM,  the  highest  predefined  modeling  element  is  the  class.  However,  a 
single  class  is  not  suited  to  Conceptual-level  alignment.  If  one  considers  the  essential 
concepts  of  M&S  (e.g.,  units,  equipment)  a  little  study  of  the  JSIMS  FOM  shows  that  sets 
of  classes  capture  these  concepts  better  than  any  individual  class. 

Therefore,  we  created  packages  as  a  first  step  in  Conceptual-level  analysis.  We  reviewed 
the  JSIMS  FOM  to  determine  the  areas  on  which  we  would  focus.  Each  area  became  a 
package. 

Each  package  consists  of  a  set  of  classes  and  complex  data  types.  One  class  or  complex 
data  type  in  the  package  is  designated  as  focal.  The  guiding  principles  in  determining 
what  to  put  in  a  package  were  as  follows: 

•  If  a  class  is  in  a  package,  the  transitive  closure  of  its  superclass  relationships  is 
too. 

•  If  a  class  has  an  attribute  whose  type  is  a  complex  data  type  D,  then  D  is  also  in 
the  package  unless  it  is  the  focal  element  of  another  package,  in  which  case  D  will 
be  assessed  separately  as  an  independent  concept. 

•  The  package  includes  the  transitive  closure  of  complex  data  types,  except  as 
qualified  by  the  rule  for  focal  elements. 

•  The  JSIMS  EOM  does  not  model  all  class  composition  relationships  explicitly. 
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The  last  point  requires  some  explanation.  The  JSIMS  FOM  objeet  model  provides  eaeh 
objeet  instanee  with  a  unique  identifier.  This  identifier  is  of  eomplex  data  type  id_c.  Dur¬ 
ing  exeeution,  the  JSIMS  FOM  provides  an  objeet  manager  that  reeords  all  eurrently  ex¬ 
isting  objeets,  and  lets  other  objeets  refer  to  them  (i.e.,  get  and  set  their  attributes) 
through  their  objeet  identifier.  Many  JSIMS  FOM  elasses  and  eomplex  data  types  eontain 
attributes  of  type  id_c.  For  example,  elass  org.land.equip_group  eontains  an  attribute 
abstractJd_o,  whieh  is  a  referenee  to  an  instanee  of  elass  abstract.  This  is  an  implieit  eom- 
position  relationship.  The  implieation  for  alignment  assessment  is  that  the  Equipment 
paekage,  whieh  eontains  org.land.equip_group,  also  eontains  abstract. 

The  LC2IEDM  has  a  set  of  predefined  views.  It  would  have  been  possible  to  use  them, 
but  they  were  ereated  to  illustrate  speeifie  EC2IEDM  eoneepts,  not  for  the  purposes  of 
alignment.  Eor  example,  there  is  no  single  view  that  eleanly  eneapsulates  an  organization 
and  its  related  entities.  Instead  there  are  views  sueh  as: 

•  ORGANISATION-AESI9s,  whieh  depiets  an  organization,  its  supertype,  and  its 
subtypes. 

•  ORGANISATION-TYPE-AES24h,  whieh  depiets  an  organization  type,  its  super¬ 
type,  and  its  subtypes. 

There  is  no  view  that  merges  the  two  exeept  the  view  that  ineludes  the  entire  EC2IEDM. 

We  therefore  deeided  to  introduee  our  own  views,  whieh  we  deliberately  attempted  to 
mateh  with  the  JSIMS  EOM  views  we  ereated.  We  used  the  following  prineiples  to  ereate 
views: 

•  We  looked  for  EC2IEDM  entities  with  names  similar  to  those  of  the  elasses  in  the 
JSIMS  EOM  paekage  to  whieh  we  were  aligning. 

•  We  tried  to  mateh  JSIMS  EOM  superelass  relationships  with  EC2IEDM  supertype 
relationships. 

•  We  read  elass  and  entity  deseriptions  to  look  for  similarities. 

•  We  studied  the  relationships  among  elements  in  the  JSIMS  EOM  paekage  and  in- 
eluded  entities  in  the  view  if  they  appeared  to  have  similar  relationships.  Interme¬ 
diate  entities  (e.g.,  assoeiative  entities)  were  ineluded  in  the  view  as  neeessary. 

The  real  work  of  Coneeptual-level  alignment  analysis  is  supposed  to  begin  at  this  point, 
with  assessors  matehing  up  paekages  and  views.  The  matehing  prineiples  are  in  faet  more 
or  less  the  prineiples  used  to  ereate  views.  We  therefore  found  we  had  eompleted  most  of 
the  Coneeptual-level  alignment  analysis  already. 

What  remained  was  to  assign  the  degree  of  alignment.  At  the  Coneeptual  level,  the  degree 
of  alignment  is  assigned  intuitively.  The  deseriptive  information  one  uses  during  Coneep¬ 
tual-level  analysis  (see  Table  1)  is  usually  in  the  form  of  natural  language,  and  does  not 
faeilitate  rigor.  With  only  the  Coneeptual  level  modeling  elements,  rigorous  analysis  is 
not  possible.  Computed  degree  of  alignment  supplies  the  neeessary  rigor  by  relating  Con¬ 
eeptual-level  assessments  to  Value-level  assessments. 

The  formula  used  was  the  pereent  of  JSIMS  EOM  elasses  in  a  paekage  that  had  a  mateh¬ 
ing  entity  in  the  eorresponding  EC2IEDM  view.  This  value  was  rounded  off  to  one  of 
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five  values:  0%,  25%,  50%,  75%,  or  100%.  The  assessor’s  judgment  regarding  the  struc¬ 
tural  compatibility  of  the  package  and  the  view  could  influence  the  flnal  value  assigned. 

The  work  products  from  Conceptual-level  analysis,  then,  are  packages,  views,  and  their 
alignment.  The  assessors  have  classified  modeling  elements  according  to  their  role.  They 
are  now  ready  to  begin  studies  of  individual  elements. 

The  true  purpose  of  Conceptual-level  analysis,  then,  is  to  organize  information  for  subse¬ 
quent  alignment.  The  partitioning  activities  that  assessors  have  undertaken  give  them  the 
foundation  for  more  rigorous  work  at  the  lower  levels. 

5. 4. 2. 2  Entity  Level 

In  Entity-level  alignment  analysis,  the  assessor  performs  one  assessment  for  every  com¬ 
ponent — either  a  class  or  a  complex  data  type — of  a  package.  The  assessor  attempts  to 
find  a  set  of  LC2IEDM  entities  that  align  to  the  JSIMS  EOM  component  he  is  assessing. 

In  the  JSIMS  EOM/EC2IEDM  study,  most  of  the  necessary  work  for  Entity-level  align¬ 
ment  analysis  was  performed  during  the  creation  of  EC2IEDM  views  matching  JSIMS 
EOM  packages.  Part  of  the  assessor’s  task  required  looking  for  entities  matching  each 
JSIMS  EOM  class  or  complex  data  type. 

In  theory,  the  difference  between  Conceptual-  and  Entity-level  alignment  analysis  is  that 
the  latter  includes  consideration  of  attribute  names.  In  practice,  we  usually  found  it  nec¬ 
essary  to  study  attribute  names  in  order  to  intuit  the  purpose  of  a  class  or  entity. 

Entity-level  alignment  analysis  entails  assigning  a  degree  of  alignment  to  each  assess¬ 
ment.  The  general  heuristic  used  is  that  the  degree  of  alignment  is  the  percentage  of  at¬ 
tribute  in  a  JSIMS  EOM  component  that  have  a  corresponding  attribute  in  an  EC2IEDM 
entity  matching  the  component.  As  in  Conceptual-level  alignment  analysis,  an  assigned 
degree  of  alignment  is  one  of  five  values:  0%,  25%,  50%,  75%,  or  100%. 

A  value  of  0%  indicates  that  no  EC2IEDM  entity  exists  that  can  model  the  information  in 
a  JSIMS  EOM  class  or  complex  data  type.  Such  an  assessment  is  called  terminal.  There 
is  no  need  to  drill  down  further,  because  no  EC2IEDM  attributes  would  be  found  to 
model  the  attributes  of  the  JSIMS  EOM  class. 

An  assessor  can  also  deem  a  JSIMS  EOM  class  or  complex  data  type  irrelevant  to  align¬ 
ment  analysis.  Some  classes  have  attributes  that  contain  simulation-system-specific  data, 
rather  than  modeling  some  aspect  of  the  real  world.  An  irrelevant  element  is  not  used  cal¬ 
culating  degree  of  alignment. 

Another  way  in  which  the  practice  of  the  EC2IEDM/JSIMS  EOM  alignment  study  dif¬ 
fered  from  the  theory  was  that  we  performed  most  of  the  Entity-level  assessments  before 
formally  performing  any  of  the  Conceptual-level  assessments.  In  other  words,  we  as¬ 
sessed  Entity-level  elements  without  having  explicitly  defined  a  context;  in  particular,  we 
assessed  many  of  the  JSIMS  EOM  classes  this  way.  (We  had  context  for  the  complex  data 
types  because  we  drilled  down  to  them.)  This  did  not  pose  a  methodological  problem  be- 
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cause  JSIMS  FOM  classes  are  not  shared;  an  attribute’s  data  type  can  be  a  complex  data 
type,  but  not  a  class.  Classes  are  not  likely  to  be  shared  between  packages.  The  underly¬ 
ing  concept  was  implicitly  known. 

We  assessed  complex  data  types  using  almost  the  same  methods  as  for  classes.  The  only 
distinction  was  that  we  considered  the  potential  for  reusing  assessments,  since  complex 
data  types  can  be  shared  across  classes  (see  Figure  16).  The  assessment  of  a  complex  data 
type  is  derived  from  an  attribute’s  assessment  (see  Figure  15). 

•  Some  complex  data  types  (e.g.,  coordinate_3d_c)  model  values  that  are  independent 
of  the  context  in  which  they  are  used.  We  wrote  assessments  of  these  types  to  be 
independent  of  context.  Whenever  we  needed  to  assess  such  a  type,  we  first  exam¬ 
ined  the  existing  Entity-level  assessments.  If  we  found  a  suitable  assessment,  we 
used  it  as  the  derivation  of  the  attribute  being  assessed. 

•  Other  complex  data  types  may  depend  on  context.  For  example,  the  values  of  id_c, 
which  models  object  identifiers,  may  depend  on  the  type  of  object  being  modeled 
(e.g.,  there  may  be  naming  conventions).  For  these  data  types,  we  always  per¬ 
formed  separate  assessments  for  each  attribute. 

The  work  products  of  Entity-level  alignment  analysis  are  the  assessments  of  individual 
JSIMS  EOM  classes  and  complex  data  types  with  respect  to  EC2IEDM  entities.  The  as¬ 
sessor  has  identified  any  JSIMS  EOM  elements  that  do  not  align  at  all,  and  has  gathered 
enough  information  to  consider  the  degree  to  which  individual  attributes  align. 

5. 4. 2. 3  State  Level 

In  State-level  alignment  analysis,  an  assessor  determines  the  degree  of  alignment  of  each 
attribute  of  a  class,  or  field  of  a  complex  data  type.  The  assessor  attempts  to  find 
EC2IEDM  attributes  that  model  the  information  contained  in  a  JSIMS  EOM  attribute  or 
field. 

During  Entity-level  analysis,  the  assessor  aligned  EC2IEDM  attributes  to  JSIMS  EOM 
attributes  based  mainly  on  name.  During  State-level  analysis,  the  assessor  starts  with  the 
results  from  Entity-level  analysis  and  adds  consideration  of: 

•  Datatype  name.  Similarities  or  differences  in  datatypes  can  enhance  or  inhibit 
alignment.  It  is  necessary  to  know  the  naming  conventions  in  each  model:  a 
JSIMS  EOM  data  type  that  ends  with  _e  contains  an  enumerated  set  of  values,  as 
does  an  EC2IEDM  attribute  whose  name  ends  with  -CODE.  Eor  enumerations,  it  is 
also  usually  necessary  to  quickly  examine  each  set  of  values,  although  a  detailed 
examination  can  wait  until  Value-level  analysis. 

•  Datatype  atomicity.  If  the  JSIMS  EOM  datatype  is  an  atomic  type,  such  as  string  or 
long,  then  the  JSIMS  EOM  attribute  generally  aligns  to  a  single  EC2IEDM  attrib¬ 
ute  (occasionally  more  than  one;  see  below).  If  the  JSIMS  EOM  datatype  is  a 
complex  data  type,  it  is  usual  to  expect  it  to  align  to  a  larger  set  of  EC2IEDM  at¬ 
tributes. 

The  preferred  approach  for  performing  a  State-level  assessment  of  an  attribute 
whose  data  type  is  complex  is  to  postpone  enumerating  all  of  the  EC2IEDM  at- 
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tributes  that  would  align  to  the  eomplex  data  type.  Instead,  the  assessor  should 
satisfy  himself  that  the  LC2IEDM  eontains  at  least  some  viable  attributes  (if  he 
eannot,  he  assigns  a  0%  degree  of  alignment  to  the  State-level  assessment  of  the 
JSIMS  FOM  attribute),  then  perform  an  Entity-level  alignment  analysis  of  the 
eomplex  data  type.  Onee  he  has  drilled  down  from  that  analysis,  he  ean  use  the 
union  of  the  EC2IEDM  attributes  identified  during  State-level  alignment  analyses 
as  the  set  of  EC2IEDM  attributes  that  align  to  the  original  JSIMS  FOM  attribute. 

•  Attribute  cardinality.  If  a  JSIMS  FOM  attribute’s  eardinality  is  “I”,  then  there  is 
one  instanee  of  that  attribute’s  value  per  instanee  of  a  elass.  If  JSIMS  FOM  elass 
C  eontains  an  attribute  A  with  a  eardinality  of  1 ,  and  if  C  aligns  at  the  Entity  level 
to  FC2IEDM  entity  E,  then  E  must  have  an  attribute  (or  perhaps  set  of  attributes) 
that  ean  model  the  domain  of  A.  But  the  situation  is  more  eomplex  if  ^J’s  eardinal¬ 
ity  is  not  1 . 

The  usual  approaeh  if  an  attribute’s  eardinality  is  other  than  1  is  to  look  for  an 
FC2IEDM  entity  E'  that  eontains  attributes  that  model  A,  and  is  related  to  F  by  a 
many-to-one  relationship.  The  FC2IEDM  does  not  plaee  eonstraints  on  relation¬ 
ships,  so  a  many-to-one  relationship  ean  model  eardinalities  of  0+,  1+,  2+,  9,  and 
160  (all  of  whieh  appear  in  the  JSIMS  FOM).  However,  an  assessor  seldom  finds 
an  E'  related  direetly  to  E.  The  more  usual  ease  is  that  E  and  E'  have  a  many-to- 
many  relationship  via  an  assoeiative  entity.  This  is  perfeetly  aeeeptable. 

Oeeasionally,  eardinality  other  than  one  maps  to  separate  attributes  rather  than  a 
relationship.  The  JSIMS  FOM  sometimes  uses  an  array  of  three  double  values  to 
represent  a  eoordinate.  In  the  FC2IEDM,  this  aligns  to  a  single  instanee  of  a 
POINT. 

•  Attribute  units.  Many  JSIMS  FOM  attributes  with  atomie  data  types  have  units; 
for  instanee,  latitudes  are  expressed  in  degrees.  Where  available,  units  should  be 
eompared  to  those  of  eandidate  FC2IEDM  attributes.  Sometimes  JSIMS  FOM 
and  FC2IEDM  attributes  share  units,  making  alignment  straightforward.  Some¬ 
times  the  attributes  have  different  units,  neeessitating  a  eonversion  algorithm.  And 
sometimes  the  attributes  have  ineompatible  units  (e.g.,  eertain  eapabilities). 

•  Class  supertype.  If  a  JSIMS  FOM  elass  C  has  a  superelass,  then  State-level 
alignment  eonsiders  whether  the  attributes  of  that  superelass  ean  be  modeled  so  as 
to  relate  1:1  to  an  instanee  of  C.  The  assessor  looks  in  the  FC2IEDM  for: 

•  A  supertype  entity  eorresponding  to  the  superelass. 

•  Additional  attributes  in  the  entity  modeling  other  attributes  of  C. 

•  A  relationship  from  the  entity  modeling  C’s  attributes  to  another  entity  with 
attributes  that  ean  model  the  superelass. 

The  assessor  must  always  eonsider  strueture  during  State-level  alignment  assessment.  If  a 
JSIMS  FOM  elass  C  has  attributes  (Hj  ,  ^2 , . . . ,  ,  and  the  assessor  identifies  a  mapping 
of  this  set  to  FC2IEDM  attributes  {Li,L2,...,L^] ,  then  there  must  exist  a  relationship 
among  all  the  Ffs  that  maintains  the  eardinality  relationship  that  exists  between  the  H/’s. 

Seetion  5. 4.2. 2  diseussed  the  id_c  eomplex  data  type  that  many  JSIMS  FOM  elasses  uses 
to  identify  or  referenee  objeet  instanees.  The  usual  name  for  the  attribute  that  identifies  a 
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class  is  id_u.  When  assessing  a  elass,  the  assessor  finds  the  LC2IEDM  attribute  L  to  which 
id_u  aligns.  When  he  assesses  other  attributes  of  the  elass,  he  first  aseertains  if  the  eorre- 
sponding  LC2IEDM  attribute  relates  properly  to  ^4. 

The  assessor  must  be  eareful  not  to  assign  multiple  roles  to  a  single  EC2IEDM  attribute, 
and  must  try  to  mateh  attributes  aeeording  to  purpose.  Eigure  17  shows  hierarehies  for 
units  in  the  two  models.  Both  sets  have  assorted  attributes  that  ean  model  an  organiza¬ 
tion’s  name;  the  issue  is  whieh  attributes  align  to  whieh.  An  assessor  might  align  org_name 
to  either  of  object-item-name  or  unit-formal-abbreviated-name.  If  he  ehooses  unit-formal-abbreviated- 
name,  he  eannot  also  align  agg_org_name  to  unit-formal-abbreviated-name. 

Some  attributes  are  irrelevant  to  alignment.  Typieally  these  attributes  are  simulation- 
speeifie.  When  an  assessor  finds  sueh  an  attribute,  he  should  reeord  that  faet  and  not  pur¬ 
sue  its  alignment  further. 

At  the  State  level,  the  assessor  assigns  a  degree  of  alignment  based  on  the  faetors  listed 
above.  As  before,  the  value  is  0%,  25%,  50%,  75%,  or  100%.  There  is  no  speeifie  for¬ 
mula,  but  the  following  points  should  be  noted; 

•  A  degree  of  alignment  of  0%  is  appropriate  if  the  EC2IEDM  eontains  no  attribute 
that  ean  model  the  same  information  as  the  JSIMS  EOM  attribute  in  sueh  a  way  as 
to  be  strueturally  related  to  the  rest  of  the  attributes  in  the  class.  If  the  assessor  as¬ 
signs  0%  as  a  degree  of  alignment,  he  does  not  drill  down  to  the  Entity  or  Value 
level. 

•  Some  JSIMS  EOM  attributes  translate  to  different  struetural  representations  in  the 
EC2IEDM  (e.g.,  the  locationjype  attribute  of  elass  org).  They  ean  be  eonsidered 
terminal. 

•  The  assessor,  when  assessing  a  JSIMS  EOM  attribute  whose  data  type  is  atomie, 
has  usually  studied  the  attributes  fairly  elosely  and  bases  the  degree  of  alignment 
on  his  intuitive  pereeption  of  the  degree  to  whieh  the  attribute  domains  will  over¬ 
lap.  With  praetiee  this  number  tends  to  be  elose  to  that  assigned  in  Value-level  as¬ 
sessment. 

•  When  the  assessor  is  eonsidering  a  JSIMS  EOM  attribute  whose  data  type  is  a 
eomplex  data  type,  he  might  base  the  degree  of  alignment  on  whether  the 
EC2IEDM  eontains  an  entity  with  a  name  similar  to  that  of  the  eomplex  data  type. 

Even  if  the  degree  of  alignment  is  greater  than  0%,  an  assessor  may  declare  an  assess¬ 
ment  terminal.  This  was  eommon  in  the  AICDM/OMSC  study  [WHEH2001],  beeause 
the  assessor  often  found  that  the  OMSC  was  too  vague  to  faeilitate  further  analysis.  It 
was  uneommon  in  the  WARSIM/EC2IEDM  study,  whieh  is  fortunate,  beeause  stopping 
at  the  State  level  inereases  the  overall  subjeetivity  of  the  alignment  assessment. 

After  performing  State-level  assessments,  the  assessor  has  eolleeted  the  domains  to  be 
aligned.  He  is  now  ready  to  eompare  the  domains  during  Value-level  assessment. 

5. 4. 2. 4  Value  Level 

At  the  Value  level,  the  assessor  eonsiders  domains  and  the  degree  to  whieh  they  overlap. 
A  Value-level  assessment  derives  from  a  State-level  assessment,  in  whieh  the  assessor  is 
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Figure  17.  Potential  Attribute  Mappings 

comparing  a  JSIMS  FOM  domain  such  as  string  or  long  to  a  set  of  LC2IEDM  domains. 
Usually  the  set  of  LC2IEDM  domains  has  only  one  element,  but  oeeasionally  a  JSIMS 
EOM  domain — partieularly  an  enumerated  type — aligns  to  multiple  EC2IEDM  domains. 

Value-level  alignment  assessments  are  always  terminal  and  always  relevant.  There  is  no 
rolled-up  degree  of  alignment  eomputed  from  derived  assessments.  The  assigned  degree 
of  alignment  is  the  value  used  to  derive  a  State-level  eomputed  degree  of  alignment. 

Assessors  ealeulate  the  assigned  degree  of  alignment  aeeording  to  established  proeedures. 
The  proeedures  used  in  the  EC2IEDM/JSIMS  EOM  assessment  are  in  Appendix  E.  The 
value  is  a  pereentage.  The  idea  is  that  this  pereentage  expresses  the  degree  to  whieh  the 
EC2IEDM  domain  (or  domains)  overlaps  the  JSIMS  EOM  domain. 

The  ealeulation  must  aeeount  for  the  expeeted  range  of  the  JSIMS  EOM  domain.  Both 
the  JSIMS  EOM  and  the  EC2IEDM  store  WGS-84  eoordinates.  The  JSIMS  EOM  stores 
them  using  a  double.  The  EC2IEDM  uses  NUMBER(9,6),  NUMBER(10,6),  and  NUMBER(12,3)  to 
store  latitude,  longitude,  and  elevation,  respeetively.  A  double  ean  represent  quantities  of 
both  greater  magnitude  and  greater  preeision  than  any  of  the  three  EC2IEDM  domains. 
However,  the  EC2IEDM  domains  are  adequate  for  all  possible  magnitudes,  and  they  ean 
model  position  to  within  11  em,  a  resolution  small  enough  for  WARSIM.  We  therefore 
eonelude  that  eaeh  domain  aligns  fully  to  its  respeetive  JSIMS  EOM  domain. 

The  approaeh  used  to  assess  domains  of  enumerated  data  types  was  to  ereate  a  table  of 
the  JSIMS  EOM  values  and,  for  eaeh  value,  identify  whieh  ones  had  an  unambiguous 
mapping  to  EC2IEDM  values.  Eigure  18  shows  an  example  table,  used  in  the  alignment 
of  a  TCDM  enumerated  domain  for  the  Hydrological  Category  attribute  to  the  domain  of  the 
EC2IEDM  GEOGRAPHIC-FEATURE-TYPE-CATEGORY-CODE  attribute.  The  values  in  the  left- 
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most  column  are  from  the  TCDM;  those  in  the  two  right  columns  are  from  the 
LC2IEDM,  along  with  explanations.  Of  the  eleven  TCDM  values,  four  are  deemed  not 
applicable  (N/A)  to  the  alignment  assessment.  Of  the  remaining  seven,  three — Unknown, 
Data  Withheld,  and  Other — map  unambiguously  to  LC2IEDM  values.  Three  of  the  other  four 
could  map  to  any  of  several  EC2IEDM  values,  and  one  (Not  Applicable)  has  no  eorrespond- 
ing  value  in  the  EC2IEDM.  The  degree  of  alignment  is  therefore  3/7,  or  43%. 

5. 4. 2. 5  Computed  Degree  of  Alignment 

The  completed  Value-level  analyses  provide  enough  information  to  caleulate  the  com¬ 
puted  degrees  of  alignment  for  a  Conceptual-level  assessment.  Eor  any  JSIMS  EOM  ele¬ 
ment  j,  let  ADoA(/)  represent  its  assigned  degree  of  alignment,  and  let  CDoA(/)  represent 
its  computed  degree  of  alignment.  We  used  the  formulas  shown  in  Table  6  to  caleulate 
CDoA(/).  (Relevanee  means  that  the  assessment  is  not  “not  applicable”.) 


Table  6.  Formulas  Used  to  Calculate  Computed  Degree  of  Alignment 


Level 

Formula 

Conceptual 

For  a  JSIMS  FOM  package  P, 

CDoA/P)  =  average((CZ)oT(C,- )) 

where  Cj  is  a  class  that  is  part  of  P  and  the  assessment  of  Cj  is  relevant. 

Entity 

For  a  JSIMS  FOM  class  C  whose  assessment  is  relevant, 

•  If  the  assessment  of  C  is  terminal,  then  CDoA(C)  =  ADoA(C) . 

•  If  the  assessment  of  C  is  not  terminal,  then 

CDoA(C)  =  average(CDoA(T,.))x  / 

where: 

•  Aj  is  an  attribute  of  C,  or  an  ancestor  class  of  C,  whose  assessment  is 
relevant. 

•  /  is  an  adjustment  factor  as  defined  helow. 

State 

For  a  JSIMS  FOM  attribute  A  whose  assessment  is  relevant, 

•  If  the  assessment  of  A  is  terminal,  then  CDoA(T)  =  ADoA(T) . 

•  If  the  assessment  of  A  is  not  terminal,  then 

CDoA(T)  =  average((CZ)oT(e; )) 
where  e,  is  the  data  type  of  A. 

Two  aspects  of  Entity-level  eomputed  degree  of  alignment  merit  further  discussion.  The 
first  is  the  adjustment  factor  for  non-standard  mappings,  discussed  in  detail  in  Sec¬ 
tion  4.5.4.  Second,  observe  that  the  degree  of  alignment  for  a  elass  is  computed  based  on 
the  averages  of  not  only  the  attributes  of  that  elass  but  of  the  elass’  aneestors,  if  any.  A 
subelass  eannot  be  instantiated  without  instantiating  its  superelass  as  well.  The  degree  to 
whieh  a  subelass  can  align  therefore  depends  on  the  degree  to  whieh  its  superelass  can 
align. 

5.5  LC2IEDM-to- JSIMS  FOM  Assessment 

This  section  discusses  the  proeess  for  alignment  where  the  question  is  the  degree  to 
whieh  the  JSIMS  EOM  ean  model  EC2IEDM  elements.  The  process  is  similar  to  that 
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covered  in  Seetion  5.4,  but  the  difFerenee  between  the  JSIMS  FOM  and  LC2IEDM  mod¬ 
eling  elements  changes  certain  details. 

5.5.1  Process 

Figure  19  depiets  the  proeess  for  LC2IEDM-to- JSIMS  EOM  alignment  assessment.  The 
process  is  much  closer  to  the  template  in  Eigure  14  than  that  for  JSIMS  EOM-to- 
EC2IEDM  assessment  in  Eigure  15.  In  the  EC2IEDM,  all  attribute  domains  are  atomic, 
meaning  there  is  no  need  for  eyeles  between  Entity-  and  State-level  alignment  assess¬ 
ment. 


5.5.2  Level-Specific  Details 

5 . 5 . 2 . 1  Conceptual  Level 

By  the  time  the  LC2IEDM-to-JSIMS  EOM  assessment  began,  the  JSIMS  EOM-to- 
EC2IEDM  assessment  had  almost  ended.  Packages  and  views  had  been  identified  for 
JSIMS  EOM-to-EC2IEDM  Conceptual-level  analysis.  We  deeided  to  use  them  as  a  start¬ 
ing  point  for  the  EC2IEDM-to- JSIMS  EOM  assessment.  The  EC2IEDM  has  some  prede¬ 
fined  views,  but  they  are  tightly  foeused  around  a  single  entity  (sueh  as  OBJECT-ITEM)  and 
refleet  modeling  more  than  domain  concerns.  The  views  we  had  already  defined  were 
based  on  C2  domain  elements  and  seemed  more  appropriate. 

5. 5. 2. 2  Entity  Level 

The  LC2IEDM  has  some  entities  that  are  supertypes  of  more  speeific  entities.  These  su¬ 
pertypes  tend  to  be  highly  abstract,  more  so  than  any  elass  that  exists  in  The  JSIMS 
FOM.  An  example  is  OBJECT-ITEM.  The  JSIMS  FOM  has  elass  org,  whieh  maps  better  to 
ORGANISATION— a  subtype  of  OBJECT-ITEM. 

To  the  degree  that  these  high-level  entities  align  to  anything  in  the  JSIMS  FOM,  they 
aligned  to  several  JSIMS  FOM  elasses.  Often  it  was  helpful  to  keep  eontext  in  mind. 
When  assessing  the  OBJECT-ITEM  entity  within  the  eontext  of  the  Organization  eoneept, 
OBJECT-ITEM  aligns  to  class  org.  Within  the  eontext  of  the  Equipment  concept,  OBJECT- 
ITEM  aligns  to  classes  equipment  and  platform. 

Some  EC2IEDM  entities  exist  to  provide  many-to-many  assoeiations  between  other  enti¬ 
ties.  An  example  is  OBJECT-ITEM-TYPE,  whieh  relates  OBJECT-ITEM  and  OBJECT-TYPE. 
These  assoeiative  entities  have  attributes,  but  to  align  them  means  more  than  just  relating 
their  attributes.  It  is  also  necessary  to  consider  the  entities  they  relate,  and  to  determine  if 
the  JSIMS  FOM  supports  the  same  strueture.  (As  a  rule  the  JSIMS  FOM  does  not;  the 
JSIMS  FOM  generally  supports  one-to-many  but  not  many-to-many  relationships.) 

5. 5. 2. 3  State  Level 

The  LC2IEDM-to- JSIMS  FOM  alignment  is  fundamentally  different  from  the  JSIMS 
FOM-to-EC2IEDM  alignment  in  the  need  to  align  attributes  that  are  foreign  keys.  The 
JSIMS  FOM  has  a  few  attributes  that  serve  a  similar  role  (e.g.,  the  abstract_id_o  attribute 
associated  with  many  classes),  but  the  prevalence  of  foreign  keys  in  a  relational  model 
demands  some  new  approaehes  to  alignment. 
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TCDM: 

Hydrological  Category 
Unknown 


Value  Intentionally 
Left  Blank 


Not  Applicable 


Dry 


Value  Intentionally 
Left  Blank 


Value  Intentionally 
Left  Blank 


Non-Perennial  / 
Intermittent  / 
Fluctuating 


Value  Intentionally 
Left  Blank 


Perennial  /  Permanent 


Data  Withheld 


Other 


LC2IEDM: 

GEOGRAPHIC-FEATURE-TYPE-CATEGORY-CODE 


Not  known 

It  is  not  possible  to  determine  which  value  is 
most  applicable. 

N/A 

No  match 

Cliff/escarpment 

A  steep,  vertical,  or  overhanging  face  of  rock 
or  earth. 

Dry  gap 

A  waterless  ravine  or  mountain  pass. 

Mountain 

A  natural  elevation  of  the  earth's  surface 
having  considerable  mass,  generally  steep 
sides,  and  a  height  greater  than  that  of  a  hill. 

Ridge  line 

Line  representation  of  ridge  top. 

N/A 

N/A 

Ford 

A  shallow  part  of  a  body  of  water  that  can  be 
crossed  without  bridging,  boats,  or  rafts.  A 
location  in  a  water  barrier  where  the  physical 
characteristics  of  current,  bottom,  and  ap¬ 
proaches  permit  the  passage  of  personnel 
and/or  vehicles  and  other  equipment. 

Mountain  pass 

A  natural  route  through  a  low  place  in  a 
mountain  range. 

River/stream 

A  natural  flowing  watercourse. 

N/A 

Ford 

Lake/pond 

A  natural  body  of  water  surrounded  by  land. 

Marsh/swamp 

A  saturated  area,  at  times  covered  with  wa¬ 
ter,  supporting  vegetation  which  may  include 
trees. 

River/stream 

A  natural  flowing  watercourse. 

Water  (except 
inland) 

An  area  of  water  which  normally  has  tidal 
fluctuations. 

No  match 

Not  otherwise 
specified 

The  appropriate  value  is  not  in  the  set  of 
specified  values. 

Figure  18.  Example  Table  for  Value-Level  Alignment  Analysis 


A  foreign  key  deseribes  a  struetural  relationship.  If  entity  E\  has  a  foreign  key  / that  is  a 
key  of  E2,  a  one-to-many  relationship  exists  between  E2  and  Ei.  Thus,  if  Ei  aligns  to  elass 
Cl  and  E2  aligns  to  elass  C2,  then  /  aligns  if  C2  has  an  attribute  with  a  eardinality  of  0+ 
whose  data  type  aligns  to  Ei  (at  the  Entity  level),  or  to  a  supertype  of  Ei.  (Cardinality  of 
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Level 


Process  Step 


Conceptual  For  each  LC2IEDM  view, 
align  JSIMS  packages 


i 


Entity 


State 


Value 


A 


Drill  down  (assign 
degree  of  alignment) 

Roll  up  (compute 
degree  of  alignment) 


For  each  LC2IEDM  entity  in  a  view,  align 
JSIMS  classes  and  complex  data  types 


For  each  entity  attribute, 
align  JSIMS  attributes 


i 


Align  each  attribute’s  domain 


Figure  19.  LC2IEDM  to  JSIMS  FOM  Alignment  Assessment  Process 

1+  indicates  partial  alignment.  Cardinality  of  1  indicates  minimal  alignment,  and  must  be 
considered  case  by  case.) 


A  foreign  key  can  also  describe  a  subtype  relationship.  If  entity  Ec  has  a  foreign  key /that 
is  migrated  from  parent  entity  E^,  and  if  E^  aligns  to  C\  and  E^  aligns  to  Ci,  then  /  aligns 
if  Cl  is  a  subelass  of  C2. 


A  supertype  entity  E  has  an  attribute  whose  name  has  the  form  E-CATEGORY-CODE.  This 
attribute  discriminates  a  category  of  instances  comprising  the  subtype.  Usually  its  align¬ 
ment  is  obvious  from  the  context  of  the  Conceptual  level  assessment.  In  the  context  of  the 
Unit  concept,  the  value  of  OBJECT-ITEM-CATEGORY-CODE  is  always  OR  (organization).  In 
the  context  of  the  Equipment  concept,  the  value  of  OBJECT-ITEM-CATEGORY-CODE  is  al¬ 
ways  MA  (materiel). 

The  LC2IEDM  entity  CAPABILITY  has  an  attribute  CAPABILITY-ID.  This  attribute  is  a  foreign 
key  in  several  other  entities,  including  OBJECT-TYPE-CAPABILITY-NORM.  Capabilities  are 
expressed  in  the  JSIMS  EOM  using  attributes  of  class  abstract  (or  its  subclasses).  The 
number  of  capabilities  that  will  be  associated  with  an  object  type  is  bounded  by  the  num¬ 
ber  of  capability  codes  that  are  relevant  to  the  object  type. 

In  other  words,  CAPABILITY-ID  aligns  insofar  as  the  various  capability  codes  can  be  mod¬ 
eled.  Its  assessment  is  therefore  entirely  dependent  on  other  attributes.  It  is  therefore  con¬ 
sidered  not  applicable,  because  assessing  it  would  duplicate  other  assessments  and  skew 
the  computed  degree  of  alignment. 

5. 5. 2. 4  Value  Level 

In  general,  the  issues  in  performing  Value-level  alignment  were  the  same  as  for  the 
JSIMS  EOM-to-EC2IEDM  direction.  The  assessment  was  usually  simpler,  because 
JSIMS  EOM  domains  tend  to  be  broader  than  EC2IEDM  domains; 
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•  Where  the  LC2IEDM  uses  NUMBER(n),  n<6,  to  represent  a  numerie  quantity  (as 
opposed  to  an  entity  instanee  identifier)  the  JSIMS  FOM  uses  long. 

•  Where  the  LC2IEDM  uses  NUMBER(n)  ,  n<18,  to  represent  an  entity  instanee  iden¬ 
tifier,  the  JSfMS  FOM  uses  string,  whieh  ean  be  as  long  as  2^^  - 1  charaeters. 

•  Where  the  EC21EDM  uses  NUMBER(n,m),  n<13  and  m<6,  to  represent  a  numerie 
quantity,  the  JSIMS  FOM  uses  double. 

•  Where  the  FC21EDM  uses  VARCHAR(n)  ,  n<2000,  to  represent  a  string,  the  JSIMS 
FOM  uses  string. 

The  implieation  is  that  it  is  always  possible  to  eonvert  an  FC21EDM  domain  to  a  JSIMS 
FOM  domain  and  baek  again  without  loss  of  preeision.  The  only  area  where  problems 
might  arise  is  in  aligning  floating-point  domains,  beeause  NUMBER(n,m)  is  a  deeimal  repre¬ 
sentation  and  double  is  a  binary  representation.  However,  in  the  domains  we  assessed, 
eonversion  errors  in  numerie  domains  would  have  resulted  in  differenees  that  were 
judged  insignifieant. 
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6.  WARSIM  LC2IEDM  Alignment  Assessment 

Results 


This  section  presents  the  results  of  assessing  the  degree  of  alignment  going  from  the 
WARSIM  to  the  LC2IEDM  using  the  process  described  in  Section  5.  These  results  can  be 
summarized  for  the  three  main  conceptual  areas  as  follows: 

Table  7.  Degrees  of  Alignment  of  the  LC2IEDM  with  Respect  to  WARSIM  Concepts 


Conceptual  Area 

Degree  of  Alignment 

Unit 

61% 

Equipment 

70% 

Environment 

41% 

6.1  Unit  Area 

6.1.1  Overview  of  U nit  Area  Alignments 

WARSIM  and  the  LC2IEDM  both  have  explicit  entities  for  representing  military  units. 
WARSIM  has  the  org. land. unit  object  class,  which  corresponds  to  the  UNIT  subclass  of  the 
ORGANIZATION  entity  in  the  EC2IEDM.  The  WARSIM  org. land. unit  object  class  is  part  of  a 
three  class  hierarchy  reflected  in  its  naming  structure.  Class  definitions  for  these  WAR¬ 
SIM  Unit  area  classes  are  given  in  Table  8.  Although  this  is  a  simple  hierarchy  on  the  sur¬ 
face,  it  is  greatly  enriched  by  its  many  complex  attributes  which  support  representation  of 
related  platforms,  crew,  and  their  attributes. 


Table  8.  JSIMS  FOM  Classes  that  Model  Unit 


JSIMS  FOM 
Class 

Definition 

org 

A  collection  of  personnel  and/or  equipment  and/or  supplies. 

org.  land 

Land  organizations. 

org. land. unit 

A  collection  of  personnel,  equipment,  and  supplies  having  some  cognitive 
behavior.  May  represent  either  military  or  civilian  groups. 

The  EC2IEDM  has  a  much  richer  entity  level  representation  of  units,  their  attributes,  and 
relationships  because  its  third  normal  form  Entity-Relationship  (ER)  format  imposes 
modeling  constraints  that  eliminate  duplicative  information  and  require  all  attributes  to  be 
simple  atomic  values.  A  view  of  the  principal  EC2IEDM  entities  required  to  represent 
Unit  data  from  WARSIM  is  illustrated  in  Eigure  20.  This  differs  from  the  core  EC2IEDM 
unit  view  (Eigure  7  on  p.  21)  because  the  unit  entities  in  WARSIM  include  much  equip¬ 
ment  related  data.  In  Eigure  20,  UNIT  is  identified  as  a  subtype  of  ORGANISATION,  which  is 
a  subtype  of  OBJECT-ITEM,  which  is  related  to  the  types  of  unit  via  the  OBJECT-ITEM-TYPE 
relationship,  where  the  UNIT-TYPE  is  a  subtype  of  ORGANISATION-TYPE,  which  is  a  subtype 
of  OBJECT-TYPE.  The  WARSIM  agg_org_name  attribute  of  a  unit  corresponds  to  the  unit- 
formal-abbreviated-name  attribute  of  the  UNIT  entity. 
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Figure  20.  Principal  LC2IEDM  Entity  Structure  for  WARSIM  Unit  Data 


Authorized  levels  of  equipment  and  personnel,  as  modeled  in  WARSIM,  are  identified  in 
the  LC2IEDM  via  the  ORGANISATION-ORGANISATION-TYPE-ESTABLISHMENT  entity,  linked  to 
the  ORGANISATION-TYPE-ESTABLISHMENT  entity  whieh  links  to  ORGANISATION-TYPE- 
ESTABLISHMENT-MATERIEL-TYPE-DETAIL  to  list  types  of  authorized  equipment  (via 
MATERIEL-TYPE  and  EQUIPMENT-TYPE)  and  to  ORGANISATION-TYPE-ESTABLISHMENT- 
PERSON-TYPE-DETAIL  to  list  the  types  of  authorized  personnel  (via  PERSON-TYPE)  and  their 
assoeiated  authorized  quantities. 

The  WARSIM  org. land. unit  data  on  rules  of  engagement  for  air  and  ground 
(air_rules_of_engagement_o,  ground_rules_of_engagement_o)  could  be  mapped  into  the  text  field 
(rule-of-engagement-description-text)  of  the  LC2IEDM  RULE-OF-ENGAGEMENT  entity.  A  UNIT  is 
linked  to  a  RULE-OF-ENGAGEMENT  through  the  associations  ORGANISATION-ACTION-TASK 
and  ACTION-RULE-OF-ENGAGEMENT.  But  many  specific  details  of  rules  of  engagement  are 
best  represented  elsewhere  in  the  EC2IEDM.  The  engagement  and  fire  restricted  areas 
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specified  in  WARSIM  can  be  defined  geospatially  by  the  SURFACE  and  POINT  subtypes  of 
the  LOCATION  entity,  which  is  linked  to  CONTROL-FEATURE  by  the  FEATURE-LOCATION 
assciation  to  specify  the  type  of  control.  A  UNIT  may  be  linked  to  such  a  control  feature 
through  its  ORGANISATION  supertype  via  the  ORGANISATION-CONTROL-FEATURE- 
ASSOCIATION.  Alternatively,  for  rules  of  engagement  restricted  to  specific  tasks,  a  UNIT 
can  be  linked  to  a  suitable  control  feature  through  the  ACTION-OBJECTIVE-ITEM  association 
for  an  ACTION-TASK  which  is  associated  with  the  unit  through  the  ORGANISATION-ACTION- 
TASK-ASSOCIATION. 

WARSIM  data  on  fire  thresholds  and  weapon  control  status  (fire  threshold, 
weapon_control)  for  a  UNIT  can  be  partially  captured  in  the  ORGANISATION-STATUS  entity 
of  the  LC2IEDM.  WARSIM ’s  list  of  a  unit’s  types  of  air  targets  is  only  partially  covered 
by  the  LC2IEDM  via  its  ACTION-OBJECTIVE-TYPE,  EQUIPMENT-TYPE  entities  which  are  as¬ 
sociated  with  an  ACTION-TASK  linked  to  the  UNIT  entity  via  ORGANISATION-ACTION-TASK- 
ASSOCIATION  in  the  EC2IEDM.  WARSIM  priorities  for  a  unit  on  such  targets  are  fully 
covered  via  a  priority  code  in  the  ACTION-OBJECTIVE  entity.  WARSIM’s  data  on  a  unit’s 
ground  targets  is  left  to  a  free-form  text  field,  which  could  be  mapped  into  the  free  text 
field  of  RULE-OF-ENGAGEMENT,  or  which  might  be  parsed  out  to  the  same  entities  used  for 
air  targets. 

The  types  of  platforms  (platform_midbs_o)  which  are  currently  held  by  a  unit  are  specified 
by  the  category  and  subcategory  codes  of  EQUIPMENT  and  their  amounts  (platform_counts) 
are  specified  by  the  HOLDING  relationship  between  OBJECT-ITEM  (linked  to  UNIT  as  as  sub- 
type  through  ORGANISATION)  and  OBJECT-TYPE  (linked  to  EQUIPMENT  as  a  subtype  through 
MATERIEL-TYPE). 

The  link  between  a  unit  and  other  units  that  are  perceived  by  it  (perceived_units)  is  identi¬ 
fied  in  the  EC2IEDM  via  the  REPORTING-DATA  entity,  which  has  a  special  link  to  the  su¬ 
pertype  ORGANISATION  of  UNIT  to  identify  the  reporting  organization.  The  location  of  per¬ 
ceived  units  is  recorded  in  the  EC2IEDM  via  the  link  between  REPORTING-DATA  and 
ORGANISATION-POINT,  which  associates  the  organization  with  the  POINT  location  where  it 
was  perceived.  Percieved  features  have  a  similar  representation  mediated  via  the  link  be¬ 
tween  REPORTING-DATA  and  FEATURE-LOCATION. 

These  brief  descriptions  capture  the  mappings  of  typical  WARSIM  unit  data  to  the  rele¬ 
vant  entities  in  the  LC2IEDM.  A  few  illustrative  examples  follow  of  alignment  assess¬ 
ments  in  the  Unit  area  which  go  down  to  the  state  and  value  level,  matching  LC2IEDM 
attributes  and  values  to  their  corresponding  WARSIM  data  elements. 

6.1.2  Unit  Area  Example  for  Simple  Attributes 

An  example  of  mapping  Unit  area  attributes  from  WARSIM  to  the  EC2IEDM  is  illus¬ 
trated  in  Eigure  21.  The  task  attribute  of  org. land. unit  is  shown  to  map  directly  to  the  action- 
name  attribute  of  the  ACTION-TASK  entity  in  the  EC2IEDM.  However,  the  six  other  entities 
shown  are  required  to  link  the  action  task  to  the  UNIT  entity  and  to  specify  the  task  as  in 
execution  and  in  progress.  Nonetheless,  the  information  is  fully  preserved,  so  an  assess¬ 
ment  value  of  100%  is  assigned.  The  frequency  attribute  of  org. land. unit  in  WARSIM,  in 
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WARSIM  LC2IEDM 

OBJECT-ITEM  ORGANISATION-ACTION-TASK-ASSOCIATION 


Figure  21.  Example  Unit  Area  Alignment  Mapping  and  Assessments 


contrast,  has  no  corresponding  data  element  in  the  LC2IEDM,  so  it  gets  a  0%  alignment 
assessment. 

6.1,3  Unit  Area  Example  of  an  Enumeration  Attribute 

Assessment  of  enumeration  attributes  ordinarily  just  requires  eomputing  the  ratio  of  those 
enumerated  values  covered  by  a  model  over  the  total  number  of  enumerated  values  of  the 
attributed.  The  WARSIM  org_type_e  enumerated  attribute  has  three  values  (equip_group, 
supply_cache,  unit),  of  which  only  one  is  covered  by  the  LC2IEDM,  giving  an  alignment 
assessment  of  1/3  or  33%,  as  illustrated  in  Eigure  22. 

WARSIM  LC2IEDM 


NOS  (not  otherwise  specified)  NKN] 

Figure  22  Example  Unit  Area  Alignment  Mapping  of  an  Enumerated  Attribute. 
6.1,4  Unit  Area  Assessments  Summary 

Table  9  provides  summary  assessment  results  at  the  Entity-level  for  the  Unit  area.  The 
overall  degree  of  alignment  of  the  Unit  area  of  61%  is  simply  the  average  of  these  as- 
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sessments  for  org,  org.land,  and  org. land. unit.  Greater  detail  on  the  aligned  elasses  from  the 
LC2IEDM  and  the  notes  explaining  the  alignment  are  included  in  the  table  of  Appen¬ 
dix  B.  The  full  details  are  available  in  the  alignment  assessment  database. 

Table  9.  Unit  Area  Entity-Level  Assessment  Results 


WARSIM-to-LC2IEDM  Alignment 

JSIMS  FOM 
Class 

Degree  of  Alignment  to  the 
LC2DM 

org 

84% 

org.land 

54% 

org. land. unit 

46% 

Figure  23  shows  the  results  of  all  146  applicable  State-level  assessments  in  the  Unit  area 
(12  were  identified  as  not  applicable  (N/A)  due  to  irrelevance  to  C4I  systems).  This  graph 
breaks  down  the  assessment  of  alignment  in  the  Unit  area  in  terms  of  ranges  of  degree  of 
alignment  for  the  attributes.  72,  or  49%,  of  the  attributes  assessed  fully  align  (at  100%), 


Degree  of  Alignment 


Figure  23.  Unit  Area  Attribute  Alignment  Assessment  Results 


while  a  significant  minority  (11,  or  8%)  have  no  correspondence  at  all  in  the  LC2IEDM. 
Complete  State-level  assessments  are  available  in  the  alignment  assessment  database. 


6.2  Equipment  Area 

6.2.1  Overview  of  Equipment  Area  Alignments 

The  Equipment  Area  of  WARSIM’s  models  comprises  nine  JSIMS  FOM  classes  pub¬ 
lished  by  WARSIM  that  model  materiel.  They  are  summarized  in  Table  10.  (WARSIM 
does  not  actually  publish  classes  abstract  and  org,  but  as  superclasses  of  WARSIM- 
published  classes  it  is  necessary  to  consider  the  alignment  of  these  two  classes.)  This 
group  of  classes  overlaps  with  two  classes  from  the  Unit  area — org  and  org.land — ^because 
they  are  superclasses  of  the  org. land. equip_group  and  org.lang.supply_cache  classes  which  rep¬ 
resent  groups  (and  “cache’s”)  of  instances  of  equipment. 

We  performed  an  assessment  of  the  degree  to  which  WARSIM  elements  of  the  JSIMS 
FOM  related  to  materiel  align  to  EC2IEDM  elements.  We  assessed  these  classes  accord- 
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ing  to  the  process  in  Section  5.4,  drilling  down  to  the  Value  level,  and  performing  Entity- 
level  assessments  of  complex  data  types  as  necessary. 


Table  10.  JSIMS  FOM  Classes  that  Model  Equipment 


JSIMS  FOM  Class 

Definition 

abstract 

Abstract  characteristics  of  objects.  Used  to  consolidate  information 
applicable  to  many  platform  objects  (e.g.,  one  data  set  for  many  of 
the  same  model  of  tank). 

abstract.land 

Land  specific  abstract  objects. 

abstract.land.equipmentjype 

Static  characteristics  of  equipment  types. 

abstract.land. personneljype 

Static  characteristics  of  personnel  types. 

abstract,  land .  rotary_wi  ngjype 

Static  characteristics  of  helicopter  types. 

org 

A  collection  of  personnel  and/or  equipment  and/or  supplies. 

org.land 

Land  organizations. 

org.land.equip_group 

A  collection  of  platforms  making  up  a  lower  level  organization  that 
has  reactive  but  not  cognitive  behaviors. 

org.land.supply_cache 

A  collection  of  supplies,  TBD. 

Table  1 1  summarizes  the  effort  in  terms  of  number  of  elements  assessed.  From  the  single 
Conceptual-level  assessment  that  comprises  the  Equipment  concept,  we  ultimately  de¬ 
rived  46  Entity-level  assessments.  However,  only  22  of  those  assessments  were  unique. 
That  is,  the  Equipment  concept  comprises  22  distinct  Entity-level  elements  (9  classes  and 
13  complex  data  types).  Some  attributes  or  fields  of  these  elements  have  the  complex 
data  type.  Value-level  assessments  are  always  relevant  and  terminal  by  definition,  so  val¬ 
ues  for  those  cells  are  not  included. 


Table  11.  Summary  of  Element  Assessment  Effort  for  Equipment 


Level 

Number  of  Assessments 

Irrelevant 

Elements 

Terminal 

Elements 

Total 

Unique 

Conceptual 

1 

1 

0 

0 

Entity 

46 

22 

0 

0 

State 

204 

136 

19 

15 

Value 

127 

54 

The  JSIMS  FOM  Entity-level  elements  related  to  materiel  aligned  to  many  different 
EC2IEDM  entities,  as  listed  in  Table  12.  No  single  EC2IEDM  entity  dominates  the  mod¬ 
eling  of  materiel.  Because  each  EC2IEDM  entity  contains  only  attributes  that  are  in  one- 
to-one  relationship  with  each  other,  and  because  the  JSIMS  FOM  models  many  character¬ 
istics  of  materiel  using  one-to-many  relationships,  it  is  to  be  expected  that  characteristics 
of  materiel  would  be  split  across  many  entities.  Note  that  the  MATERIEL  and  EQUIPMENT- 
TYPE  entities  occur  often  in  alignment  assessments  in  relation  to  most  of  the  other  enti¬ 
ties. 

Elements  of  the  Equipment  concept  often  align  to  the  ORGANISATION  entity.  This  occurs 
because  an  ORGANISATION  is  the  EC2IEDM  equivalent  of  a  JSIMS  FOM  equipment 
group.  See  Figure  24. 
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Table  12.  LC2IEDM  Entities  That  Align  to  Equipment 


Entity  Name 

Occurrences 

Entity  Name 

Occurrences 

ABSOLUTE-POINT 

6 

ORGANISATION-MATERIEL-ASSOCIATION 

1 

CAPABILITY 

4 

ORGANISATION-ORGANISATION-ASSOCIATION 

1 

COMBAT-UNIT- 

TYPE 

1 

ORGANISATION-POINT 

1 

CONVOY 

1 

ORGANISATION-STATUS 

1 

ELEVATED- 

ABSOLUTE-POINT 

6 

ORGANISATION-TYPE 

1 

EQUIPMENT-TYPE 

4 

PERSON-STATUS 

1 

FIRE-CAPABILITY 

1 

REPORTING-DATA 

2 

HOLDING 

2 

REPORTING-DATA-ABSOLUTE-TIMING 

4 

LOGICAL- 

NETWORK 

1 

REPORTING-DATA-RELATIVE-TIMING 

1 

MATERIEL 

3 

ROUTE 

1 

MATERIEL-POINT 

1 

STORAGE-CAPABILITY 

2 

MATERIEL-STATUS 

1 

SUPPORT-UNIT-TYPE 

1 

MATERIEL-TYPE 

1 

SURVEILLANCE-CAPABILITY 

1 

OBJECT-ITEM 

5 

UNIT 

1 

OBJECT-TYPE 

4 

UNIT-TYPE 

2 

ORGANISATION 

4 

6.2,2  Equipment  Area  Example 

Several  examples  of  mapping  simple  WARSIM  attributes  from  the  equipment  area  into 
the  LC2IEDM  are  illustrated  in  Figure  25.  The  platform  name  attribute  (platform_name_o) 
for  org.land.equip_group  from  WARSIM  maps  into  the  object-item-name  attribute  of  the 
LC2IEDM,  where  the  object-item-category-code  =  “MA”  for  materiel.  The  total  number  of 
platforms  (number_of_platforms)  belonging  to  an  equipment  area  is  represented  in  the 
EC2IEDM  by  the  relationship  ORGANISATION-MATERIEL-ASSOCIATION  between  the  OR¬ 
GANISATION  entity  representing  an  equipment  group  and  the  MATERIEL  entity  representing 
a  platform’s  equipment.  The  type  of  association  is  probably  best  represented  via 
organisation-materiel-association-category-code  =  “CTRL”  to  indicate  that  the  equipment  group 

JSIMS  FOM  LC2IEDM 


Figure  24.  Modeling  a  JSIMS  FOM  Equipment  Group  Using  LC2IEDM  Entities 
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WARSIM 


LC2IEDM 


Figure  25.  Example  Equipment  Area  Attribute  Alignments 
controls  the  platform.  A  separate  instanee  of  this  association  must  be  inserted  into  an 
LC2IEDM  compliant  database  for  each  platform  type,  which  are  then  counted  to  give  the 
total  number.  Identifiers  for  platforms  (platform_id_u)  in  an  equipment  group  are  repre¬ 
sented  in  WARSIM  via  the  materiel-id  attribute  of  MATERIEL,  which  is  the  same  as  the  object- 
item-id  of  OBJECT-ITEM.  The  platform  equipment  identified  by  this  WARSIM  list  of  identi¬ 
fiers  are  the  same  ones  named  by  the  list  of  platform  names,  correlated  in  WARSIM  by 
their  position  in  these  lists.  The  LC2IEDM  has  100%  alignment  with  all  of  these  attrib¬ 
utes  from  WARSIM  beeause  they  can  all  be  perfectly  represented  and  distinguished.  But 
the  exposure  attribute,  whieh  models  the  percentage  of  the  group’s  exposure  to  fire,  has 
no  corresponding  EC2IEDM  element.  It  has  a  0%  degree  of  alignment. 

6.2.3  Equipment  Area  Assessment  Results  Summary 

Table  13  provides  summary  assessment  results  at  the  Entity-level  for  the  Equipment  area. 
The  overall  degree  of  alignment  of  the  Equipment  area  of  61%  is  simply  the  average  of 
these  assessments  for  all  area  classes.  Greater  detail  on  the  aligned  classes  from  the 
EC2IEDM  and  the  notes  explaining  the  alignment  are  included  in  the  table  of  Appen¬ 
dix  C.  The  full  details  are  available  in  the  assessment  database. 

Table  13.  Equipment  Area  Entity-Level  Asseesment  Results. 


WARSIM-to-LC2IEDM  Alignment 

JSIMS  FOM  Class 

Degree  of 
Alignment 

To  the  LC2IEDM 

abstract 

88% 

abstract.land 

86% 

abstract.land.equipment  type 

57% 

abstract.land. personnel  type 

82% 

abstract.land. rotary  wing  type 

57% 
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WARSIM-to-LC2IEDM  Alignment 

JSIMS  FOM  Class 

Degree  of 
Alignment 

To  the  LC2IEDM 

org 

84% 

org.land 

54% 

org.land.eguip  group 

53% 

org.land.supply  cache 

52% 

We  assessed  a  total  of  22  JSIMS  elasses  and  complex  types  as  part  of  assessing  alignment 
in  the  equipment  area.  This  included  State-level  assessments  of  136  attributes,  of  which 
117  were  deemed  relevant.  Figure  26  shows  that  the  majority  of  these  attributes  had  a  de- 


0%  <=50%  >50%  100% 

Degree  of  Alignment 

Figure  26.  Equipment  Area  Attribute  Alignment  Assessment  Results 
gree  of  alignment  of  100%;  however,  12  attributes  did  not  align  at  all. 

6.3  Environment  Area 

6.3.1  Overview  of  Environment  Area  Alignments 

An  alignment  analysis  was  performed  on  all  the  features  defined  in  the  TCDM  that  have 
attributes.  These  attributed  features  represent  167  of  the  929  attributes  in  revision  1.2a  of 
the  TCDM.  The  remaining  features  were  incomplete  to  the  extent  that  an  analysis  was  not 
possible.  Following  the  Entity-Level  assessment,  a  State-Level  assessment  was  per¬ 
formed  on  the  89  attributes  associated  with  features  described  in  the  TCDM.  Linally,  the 
TCDM  data  types  were  evaluated  in  60  Value-Level  assessments. 

Most  types  of  TCDM  features  were  mapped  to  the  LC2IEDM  FACILITY-TYPE  entity,  rather 
than  to  a  subtype  of  the  FEATURE  entity.  The  rationale  for  this  was  that  there  appeared  to 
be  a  direct  semantic  map  between  types  of  TCDM  features  and  LC2IEDM  FACILITY- 
TYPEs.  That  is,  not  only  did  the  LC2IEDM  include  an  entity  code  for  the  specific  feature 
under  analysis,  examination  of  the  attributes  of  the  TCDM  feature  indicated  that  the  se¬ 
mantics  of  the  feature  and  the  LC2IEDM  entity  were  very  close.  Examples  of  these 
TCDM  features  include  Airport,  Infantry  Trench,  and  Minefield. 

In  some  cases,  the  mapping  from  TCDM  features  to  LC2IEDM  entities  was  not  intuitive. 
TCDM  feature  Cleared  Way/Cut  Line/Firebreak  maps  to  the  FACILITY-TYPE  entity  in  LC2IEDM 
rather  than  to  the  CONTROL-FEATURE-TYPE  entity  because  there  was  an  exact  entity  code. 
TCDM  feature  Breakwater/Groin  was  mapped  to  FACILITY-TYPE  because  an  entity  code  exists 
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for  Jetty,  which  was  semantically  close.  TCDM  features  Hops  and  Rice  field  were  also  both 
mapped  to  the  FACILITY -TYPE  entity  in  LC2IEDM  because  an  entity  code  exists  for  Crop¬ 
land,  rather  than  to  the  GEOGRAPHIC-FEATURE-TYPE  entity,  as  one  might  have  expected. 
An  even  smaller  number  of  TCDM  features  mapped  to  the  LC2IEDM  EQUIPMENT-TYPE 
entity.  These  include  TCDM  features  Airport  Lighting,  Crane,  Disk/Dish  Antenna,  and  Nuclear 
Reactor. 

We  mapped  certain  TCDM  features  to  both  FACILITY  and  FEATURE  entities.  Such  TCDM 
features: 

•  Tend  to  have  no  analog  in  the  category  codes  of  either  FEATURE-TYPE  or  FACILITY- 
TYPE.  In  such  cases  the  mapping  is  not  intuitive.  The  preferred  mapping  would 
depend  on  how  an  application  will  use  the  data. 

•  Have  that  attributes  are  covered  by  features  and  facilities  in  the  EC2IEDM.  Ex¬ 
amples  of  such  features  are  Built-Up  Area  and  Grandstand. 

It  should  be  noted  that  we  originally  interpreted  Environmental  Data  Coding  System 
(EDCS)  Classification  Codes  as  being  part  of  the  TCDM.  In  fact  this  is  not  always  the 
case.  During  the  review  of  this  document,  we  learned  that  some  of  our  Value-level 
TCDM  assessments  use  non-TCDM  codes.  Unfortunately  we  did  not  have  the  resources 
to  revise  the  assessments.  Some  assessments  may  therefore  have  a  higher  degree  of 
alignment  than  indicated.  However,  we  do  not  expect  that  the  overall  degree  of  alignment 
for  the  Environment  area  would  change  significantly  if  we  were  to  re-conduct  these  as¬ 
sessments. 

6.3.2  Alignment  Example:  Infantry  Trench 

This  section  provides  an  example  to  illustrate  how  the  data  alignment  method  was  ap¬ 
plied  in  the  study.  It  shows  the  case  where  a  TCDM  feature.  Infantry  Trench,  was  mapped 
exactly  to  an  EC2IEDM  category  code. 

The  TCDM  feature  Infantry  Trench  was  mapped  to  the  EC2IEDM  FACILTITY-TYPE  CATEGORY 
CODE  value  TCH  (Trench).  The  TCDM  feature  is  defined  as  ''trench,  typically  integrated 
into  a  complex  obstacle  system,  to  provide  cover,  concealment,  protected  fighting  posi¬ 
tions  and  communications  capability  for  infantry."  The  EC2IEDM  entity  is  defined  as  "a 
linear  excavation  dug  for  defensive  purposes."  At  the  entity  level  this  mapping  received 
an  assigned  degree  of  alignment  of  75%.  This  measure  indicates  a  high  degree  of  align¬ 
ment,  with  minor  changes  to  one  model  resulting  in  perfect  alignment.  Eollowing  the 
alignment  methodology,  the  State  level  assessment  was  then  performed  on  each  of  the 
attributes  associated  with  Infantry  Trench.  Infantry  Trench  has  five  attributes:  Damage,  General, 
Depth  Below  Surface  Level,  Object  Identification  Number,  Preparation  for  Destruction  Completion, 
Explosive  (Fraction),  and  Width. 

Damage,  General  was  mapped  to  ACTION-EFFECT-DESCRIPTION-CODE  in  the  EC2IEDM.  In 
the  TCDM  Damage,  General  is  defined  as  "the  extent  of  physical  injury/damage  in  terms  of 
fractional  degradation  from  a  healthy  state.  The  following  interpretations  may  be  ap¬ 
plied:  1/4:  Slight  Injury/Damage,  2/4:  Moderate  Injury/Damage,  3/4:  Heavy  In¬ 
jury/Damage,  4/4:  Fatally  Injured  or  Completely  Destroyed."  In  the  EC2IEDM  ACTION- 
EFFECT-DESCRIPTION-CODE  is  defined  as  "the  specific  value  that  represents  or  denotes  the 
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type  of  outcome  of  a  specific  action  that  is  being  estimated  or  recorded”  The  mapping 
was  assigned  a  100%  degree  of  alignment.  Continuing  down  to  the  Value  level  assess¬ 
ment,  the  range  of  values  represented  by  the  TCDM  attribute  were  assessed  with  respeet 
to  the  LC21EDM.  At  the  Value  level  a  precise  degree  of  alignment  is  calculated  for  the 
attribute.  The  values  that  can  be  represented  in  the  TCDM  attribute  range  from  0  to  100, 
where  zero  indicates  no  damage.  Although  the  LC21EDM  provides  19  enumerations,  in¬ 
cluding  captured,  burning,  illuminated,  consumed,  and  suppressed,  it  does  not  include  a 
value  representing  no  damage.  Slight,  moderate,  heavy,  and  complete  damage  are  in¬ 
cluded  in  the  EC21EDM,  and  map  well  to  the  TCDM  values.  Using  the  fractional  ranges 
indicated  in  the  TCDM,  four  out  of  five  values  can  be  represented  in  the  EC21EDM. 
Thus,  an  80%  degree  of  alignment  was  assigned  for  the  attribute  Damage,  General. 

Depth  Below  Surface  Level  was  mapped  to  ELEVATED-ABSOLUTE-POINT-ELEVATION-DIMENSION 
in  the  EC21EDM.  In  the  TCDM,  Depth  Below  Surface  Level  is  defined  as  ''distance  measured 
from  the  highest  point  at  surface  level  to  the  lowest  point  of  the  object  below  the  surface. 
Recorded  values  are  positive  numbers.”  In  the  EC21EDM,  ELEVATED-ABSOLUTE-POINT- 
ELEVATION-DIMENSION  is  defined  as  "the  elevation  of  an  absolute  point  above  or  below  the 
vertical  datum  as  defined  in  the  World  Geodetic  System  1984  (WGS  84).”  The  mapping 
was  assigned  a  75%  degree  of  alignment.  The  actual  degree  of  alignment  was  then  calcu¬ 
lated  for  Depth  Below  Surface  Level  by  assessing  the  range  of  values  representable  in  the 
models.  In  the  TCDM,  the  attribute  Depth  Below  Surface  Level  is  a  single -precision  floating¬ 
point  number  that  can  hold  values  ranging  from  0-120,000  decimeters.  The  attribute 
ELEVATED-ABSOLUTE-POINT-ELEVATION-DIMENSION  in  the  EC21EDM  is  a  numeric  data  type 
with  twelve  digits,  three  following  the  decimal  point.  Every  value  representable  in  the 
TCDM  can  be  accommodated  within  the  nine  digits  provided  in  the  EC21EDM.  Thus,  a 
100%  degree  of  alignment  was  assigned  for  this  attribute. 

The  attribute  Object  Identification  Number  in  the  TCDM  was  mapped  to  OBJECT-ITEM-ID  in  the 
LC2IEDM.  In  the  TCDM  the  attribute  is  defined  as  "unique  object  identification  number 
within  a  dataset.”  In  the  EC21EDM  it  is  defined  as,  "the  unique  value,  or  set  of  charac¬ 
ters,  assigned  to  represent  a  specific  OBJECT-ID  and  to  distinguish  it  from  all  other 
OBJECT -ITEMS.”  A  100%  degree  of  alignment  was  assigned  for  this  attribute.  Proceeding 
to  the  Value  level,  the  data  types  and  the  values  that  can  be  represented  by  each  attribute 
were  assessed.  In  the  TCDM,  the  Object  Identification  Number  can  assume  any  value  in  the 
range  -2147483647  to  2147483647.  In  the  EC21EDM,  OBJECT-ITEM-ID  is  represented  as  a 
numeric  data  type  with  fifteen  digits.  All  TCDM  attribute  values  may  be  represented  in 
the  EC21EDM  attribute.  A  100%  degree  of  alignment  was  assigned  for  this  attribute. 

The  attribute  Preparation  for  Destruction  Completion,  Explosive  (Fraction)  in  the  TCDM  was 
mapped  to  the  attribute  ACTION-TASK-STATUS-COMPLETION-FRACTION  in  the  EC21EDM. 
Preparation  for  Destruction  Completion,  Explosive  (Fraction)  is  defined  as  "the  degree  to  which  a 
structure,  obstacle,  or  other  object  has  been  prepared  for  destruction  by  explosives.”  The 
EC21EDM  attribute  ACTION-TASK-STATUS-COMPLETION-FRACTION  is  defined  as  "the  por¬ 
tion  of  the  planned  ACTION-TASK  that  is  estimated  to  have  been  accomplished.”  The 
mapping  was  assigned  a  100%  degree  of  alignment.  Continuing  to  the  Value  level  as¬ 
sessment,  the  data  types  of  the  attributes  were  assessed.  The  TCDM  attribute  can  repre¬ 
sent  values  in  the  range  of  0-100.  The  EC21EDM  attribute  is  represented  as  a  numeric 
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data  type  with  six  digits,  three  after  the  deeimal  point.  All  of  the  TCDM  attribute  values 
eould  thus  be  represented  in  the  LC2IEDM  attribute.  This  mapping  was  assigned  a  100% 
degree  of  alignment. 

The  last  attribute  of  Infantry  Trench  is  Width.  Width  is  defined  as  “a  measurement  of  the 
shorter  of  two  linear  axes.  For  a  square  object,  measure  either  axis.  For  a  round  object, 
width  shall  be  equal  to  LENGTH  OR  DIAMETER.  For  a  bridge,  the  width  is  the  meas¬ 
urement  perpendicular  to  the  axis  between  the  abutments."'  This  attribute  was  mapped  to 
the  LC2IEDM  attribute  REGULAR-AREA-MINOR-DIMENSION  whieh  is  defined  as  ''the  length 
of  the  shortest  side  of  the  minimum  bounding  rectangle  of  a  specified  regular  area."  A 
75%  degree  of  alignment  was  assigned  for  this  mapping.  Assessing  the  data  types  at  the 
Value  level,  we  see  that  the  TCDM  attribute  ean  represent  values  in  the  range  of  1-300. 
The  EC2IEDM  attribute,  a  data  type  with  twelve  digits,  three  following  the  deeimal 
point,  ean  represent  eaeh  of  the  TCDM  values.  Thus,  a  100%  degree  of  alignment  was 
assigned  for  this  attribute. 

Eigure  27  shows  the  relationship  between  the  EC2IEDM  entities  that  model  a  TCDM  in¬ 
fantry  treneh.  The  identified  OBJECT-ITEM  is  assoeiated  with  a  FACILITY-TYPE;  the  speeifie 
FACILITY  has  an  assoeiated  LOCATION.  A  non-identifying  relationship  defines  the  treneh’s 
damage  and  preparation  for  destruetion. 


ACTION 


ACTION-EFFECT 


ACTION-TASK 


ACTION-OBJECTIVE 


ACTION-TASK-STATUS 


ACTION-OBJECTIVE-ITEM 


OBJECT-TYPE 


OBJECT-ITEM-TYPE 


"u _ 

OBJECT-ITEM 

p 

1 

L 

FACILITY-TYPE 


H 


LOCATION  h-m  FACILITY-LOCATION 


% 


FACILITY 


POINT 


SURFACE 


ABSOLUTE-POINT  REGULAR-AREA 


ELEVATED-ABSOLUTE-POINT 


Figure  27.  Relationship  Among  LC2IEDM  Entities  that  Model  an  Infantry  Trench 
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The  results  of  the  State  and  Value-level  assessments  are  shown  in  Table  14.  The  method¬ 
ology  now  speeifies  that  the  eomputed  degree  of  alignment  values  are  averaged,  or 
“rolled  up”,  to  provide  the  entity  level  degree  of  alignment.  Adding  the  alignments  eom¬ 
puted  for  eaeh  of  the  attributes,  and  dividing  by  the  number  of  attributes,  resulted  in  a 
96%  degree  of  alignment  for  the  feature  Infantry  Trench.  An  adjustment  was  then  applied. 
Adjustments  are  used  to  fine  tune  the  ealeulated  degree  of  alignment  when  multiple  fea¬ 
tures  in  the  TCDM  are  mapped  to  the  same  entity  in  the  LC2IEDM.  In  this  ease,  slightly 
different  data  mapped  to  the  same  entity  would  no  longer  be  distinguishable.  The  adjust¬ 
ment  was  100%  for  this  feature  as  it  uniquely  maps  to  the  eode  TCH  (Treneh)  for  the 
LC2IEDM  entity  FACILITY-TYPE. 


Table  14.  Degree  of  Alignment  of  Infantry  Trench  Attributes 


Infantry  Trench  Attribute 

Assigned  Degree  of 
Alignment 

Computed  Degree  of 
Alignment 

Damage,  General 

100% 

80% 

Depth  Below  Surface  Level 

75% 

100% 

Object  Identification  Number 

100% 

100% 

Preparation  for  Destruction 
Completion,  Explosive  (Fraction) 

100% 

100% 

Width 

75% 

100% 

6.3.3  Environment  Area  Assessments  Summary 

In  aeeordanee  with  the  alignment  study  method,  the  degree  of  alignment  of  eaeh  of  the 
features  deseribed  in  the  TCDM  is  expressed  as  a  pereentage.  The  features  and  their  de¬ 
gree  of  alignment  were  then  alloeated  to  the  appropriate  eoverage,  and  an  average  degree 
of  alignment  ealeulated  for  the  eoverage.  The  results  are  shown  in  Table  15.  This  table 
shows  that  the  overall  degree  of  alignment  of  the  EC2IEDM  with  the  TCDM  is  41%. 


Table  15.  Degree  of  Alignment  by  TCDM  Coverage 


TCDM  Coverage 

Degree  of  Alignment 

Surface  Areals 

Physiography 

24% 

Vegetation 

21% 

Urban 

36% 

Water 

26% 

Point  Culture 

53% 

Linear  and  Point  Hydrography 

30% 

Linear  and  Areal  Terrain  Obstacles 

42% 

Maritime  Trafficability 

29% 

Linear  and  Point  Transportation 

46% 

Administrative  Boundaries 

35% 

Battlefield  Elements 

73% 

Linear  Connectivity 

52% 

Signifieantly,  the  Battlefield  Elements  eoverage  provides  the  highest  degree  of  alignment 
at  73%.  One  goal  during  model  development  was  to  represent  eoncepts  from  the  war¬ 
fighter’s  perspeetive.  Surfaee  Areals  represent  eoverages  with  a  poor  degree  of  alignment 
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Figure  28.  Environment  Area  Attribute  Alignment  Assessment  Results 

with  the  LC2IEDM.  The  version  of  the  TCDM  used  in  this  study  focuses  primarily  on 
terrain,  and  does  not  yet  include  features  describing  a  complete  Synthetic  Natural  Envi¬ 
ronment  (SNE). 

Eigure  28  shows  the  results  of  79  State-level  assessments  in  the  Environment  area.  All 
were  relevant,  58  were  terminal,  and  a  majority  had  0%  alignment. 

6.4  C4I 

The  C4I  and  C2  object  classes  published  to  the  JSIMS  EOM  by  WARSIM  have  no  corre¬ 
sponding  EC2IEDM  data  elements.  Those  C4I/C2  object  classes  and  attributes  whose 
names  end  with  “_p”  (for  “private”)  are  used  only  by  WARSIM  for  initialization.  The  C4I 
object  classes  provide  an  interface  between  the  simulation  and  C4I  system  to  translate 
to/from  standard  C4I  messages  using  DTD  (Document  Type  Definition),  which  is  a  set  of 
rules  that  defines  the  elements,  and  their  attributes,  in  an  XML  (Extensible  Markup  Lan¬ 
guage)  document.  These  objects  initialize  and  hold  the  state  needed  by  the  C4I  systems. 
The  LC2IEDM  does  not  contain  data  related  to  specific  system  implementations.  Rather, 
the  LC2IEDM  represents  battlefield  objects  commonly  tracked  by  (primarily)  land-based 
command  and  control  systems.  The  following  WARSIM  C4I/C2  object  classes  were  re¬ 
viewed; 

•  c2_artifacts.land;  land-specific  C2  artifacts 

•  c2_artifacts. land. state;  parent  class  for  data  tables  required  to  the  hold  state  needed  by 
the  C4I  systems.  It  contains  four  complex  and  four  atomic  attributes  in  the  follow¬ 
ing  two  object  classes  (#complex/#atomic); 

•  c4i_handler  (2/2);  contains  the  state  of  the  C4I  handler. 

•  toc_handler  (2/2);  contains  the  state  of  the  TOC  handler. 

•  initialization. land. c4i;  superclass  for  data  tables  required  to  initialize  the  C4I  systems. 
It  contains  10  complex  and  98  atomic  C4I  attributes  in  15  object  classes.  Exam¬ 
ples  of  these  object  classes  (#complex/#atomic)  are; 

•  jsimsJnteraction_manager_p  (0/8);  C4I  handler  receives  this  Eederation  Object 
(EO),  converts  the  data  to  XML  format,  and  sends  to  CommunicationsManager  to 
write  the  JSIMSInteractionManager  XML  data  to  disk  via  C4iiRemotelnSim. 

•  communications_manager_p  (1/3);  TOCHandler  receives  this  EO  to  create 
CommunicationsManager. 
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This  study  did,  however,  assess  WARSIM  battlefield  objeets  and  attributes  related  to  C4I 
that  were  ineluded  within  the  organization/equipment  object  classes.  Examples  include 
org.land.comms_status,  org.land.terminal_status,  org.land.radio_status,  org.land.sensor_status, 
org.land_type  =  MSE  (mobile  subscriber  equipment),  org.landjype  =  SIGNAL_CORPS, 
abstract.land.radio_capability,  abstract.land.-terminal_capability,  abstract.land.sensor_capability,  and  org.- 
land.unit.terminal  address  o. 
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7.  LC2IEDM  WARSIM  Alignment  Assessment 

Results 


This  section  presents  the  results  of  assessing  the  degree  of  alignment  going  from  the 
LC2IEDM  to  WARSIM  using  the  process  described  in  Section  5.  These  results  can  be 
summarized  for  the  main  conceptual  areas  as  follows: 

Table  16.  Degree  of  Alignment  of  WARSIM  with  Respect  to  LC2IEDM  Concepts 


Conceptual  Area 

Degree  of  Alignment 

Unit 

49% 

Equipment 

42% 

Environment: 

Facility 

59% 

Geographic  Feature 

63% 

Note  that  the  alignment  assessment  of  the  Environment  area  going  in  this  direction  was 
not  completed  due  to  resource  constraints.  Since  only  two  of  the  relevant  environmental 
entities  were  assessed,  an  overall  assessment  cannot  be  assigned. 


7.1  Unit 


Eigure  29  shows  the  major  EC2IEDM  entities  that  participate  directly  in  modeling  a  unit. 
Each  unit  is  modeled  as  an  instance  of  the  UNIT  entity,  a  subtype  of  ORGANISATION,  which 
is  a  subtype  of  OBJECT-ITEM.  An  OBJECT-ITEM  has  associated  type  and  status  information. 
An  ORGANISATION  exists  in  relation  to  other  organizations,  via  the  ORGANISATION- 
ORGANISATION-ASSOCIATION  entity.  This  view  differs  from  previous  views  (see  Eigure  20) 
of  the  Unit  area  because  it  focuses  on  how  units  of  all  types  are  represented  in  the 
EC2IEDM,  independently  of  the  unit  data  modeled  by  WARSIM.  Eor  example,  it  in¬ 
cludes  the  subtypes  (SUPPORT-UNIT-TYPE,  COMBAT-UNIT-TYPE,  HEADQUARTERS-UNIT-TYPE) 
of  UNIT-TYPE,  which  were  not  needed  to  represent  WARSIM  data. 


Figure  29.  LC2IEDM  Entities  in  the  Unit  Area 
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The  LC2IEDM’s  structure  for  modeling  units  is  much  richer  than  WARSIM’s.  The  most 
significant  difference  is  that  WARSIM  only  models  subordinate  and  supporting  units, 
whereas  the  LC2IEDM  enumerates  45  different  types  of  associations  (full  control,  tacti¬ 
cal  control,  operational  control,  etc.)  between  units.  Moreover,  the  EC2IEDM  models 
some  organizational  capabilities  that  WARSIM  does  not.  Eor  instance,  the  ORGANISATION- 
ORGANISATION-TYPE-ESTABLISHMENT  entity  lets  the  EC2IEDM  describe  nominal  organiza¬ 
tional  composition  and  strength;  WARSIM  lacks  this  capability.  A  more  specific  example 
is  the  UNIT-TYPE-MOBILITY-CODE  attribute,  which  characterizes  a  unit’s  mobility;  WARSIM 
has  no  equivalent. 

Eigure  30  shows  the  results  of  the  EC2IEDM-to- WARSIM  alignment  assessment  (also 
called  “reverse”  alignment)  for  the  Unit  area.  Of  38  EC2IEDM  attributes  assessed,  half 
align  fully,  but  29%  do  not  align  at  all.  The  overall  degree  of  alignment  of  the  Unit  area 
of  WARSIM  with  respect  to  the  EC2IEDM  is  49%. 
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Figure  30.  Unit  area  Reverse  Alignment  Assessment  Results 


7.2  Equipment 

The  EC2IEDM  can  model  each  instance  of  equipment  that  an  organization  possesses  as 
an  instance  of  MATERIEL.  Eigure  31  shows  the  major  EC2IEDM  entities  that  participate  in 
modeling  equipment.  Each  instance  of  equipment  is  modeled  as  an  instance  of  MATERIEL, 
which  is  a  subtype  of  OBJECT-ITEM.  An  OBJECT-ITEM  has  associations  to  OBJECT-TYPE,  of 


OBJECT-ITEM-CAPABILITy)* - 1  OBJECT-ITaTl 


z 


I  capabilityI  Iobject-item-status  ] 
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Figure  31.  Important  LC2IEDM  Entities  for  Modeling  Equipment 
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which  MATERIEL-TYPE  is  a  subtype;  in  other  words,  an  instanee  of  MATERIEL-TYPE  models 
type  information  about  an  instanee  of  MATERIEL.  (Note  that  EQUIPMENT-TYPE  is  a  subtype 
of  MATERIEL-TYPE;  the  attributes  of  EQUIPMENT-TYPE  provide  further  information  that  is 
relevant  to  modeling  equipment,  sueh  as  dimensions  and  loaded  weight.  There  is  however 
no  LC2IEDM  entity  EQUIPMENT).  Certain  other  eapabilities  of  materiel  and  materiel  types 
are  modeled  in  the  LC2IEDM  as  instanees  of  CAPABILITY  and  its  subtypes.  Note  that  an 
instanee  of  MATERIEL  would  likely  be  assoeiated  with  one  instanee  of  MATERIEL-TYPE,  and 
multiple  instanees  of  CAPABILITY  (eaeh  deseribing  a  distinet  eapability). 

Status  is  another  important  attribute  of  equipment.  The  EC2IEDM  models  equipment 
status  via  the  MATERIEL-STATUS  entity,  whieh  is  a  subtype  of  OBJECT-ITEM-STATUS.  As 
Eigure  31  shows,  eaeh  instanee  of  MATERIEL  has  zero  or  more  assoeiated  instanees  of 
MATERIEL-STATUS.  Different  instanees  model  status  based  on  observer  and  observation 
time. 

The  JSIMS  EOM  models  instanees  of  equipment  (though  it  more  often  models  equipment 
groups;  see  Seetion  2)  as  instanees  of  the  equipment  and  platform  elasses.  The  JSIMS  EOM 
deseribes  equipment  types  as  instanees  of  elass  abstract  and  its  subelasses. 

Eigure  31  elearly  illustrates  the  rieh  set  of  equipment  modeling  relationships  that  the 
EC2IEDM  provides.  The  EC2IEDM  has  speeifie  entities  for  modeling  status  and  eapabil¬ 
ity.  WARSIM,  by  eontrast,  has  no  elasses  designated  for  deseribing  status  and  eapability; 
it  only  assigns  olass-speeifie  attributes.  Moreover,  the  EC2IEDM  provides  (resolved  via 
assoeiative  entities  sueh  as  OBJECT-ITEM-TYPE)  many-to-many  relationships  between  ma¬ 
jor  entities  (sueh  as  OBJECT-ITEM  and  OBJECT-TYPE),  whereas  WARSIM’s  elass  strueture 
only  provides  one-to-many  relationships. 

We  assessed  these  entities  aeeording  to  the  methodology  in  Seetion  5.5,  starting  at  the 
Coneeptual  level  and  drilling  down  to  the  Value  level.  Table  17  summarizes  the  effort  in 
terms  of  number  of  elements  assessed.  Erom  the  single  Coneeptual-level  assessment  that 
eomprises  the  Equipment  eoneept,  we  derived  14  Entity-level  assessments,  58  State-level 
assessments,  and  19  Value-level  assessments.  One  attribute  (CAPABILITY-ID)  was  judged  to 
be  wholly  dependent  on  other  attributes  and  therefore  irrelevant.  38  attributes  were  ter¬ 
minal.  Of  these,  20  did  not  align  to  any  JSIMS  EOM  attribute  (i.e.,  their  degree  of  align¬ 
ment  was  0).  Of  the  remaining  18,  several  had  fixed  values  (e.g.,  in  the  eontext  of  equip¬ 
ment,  the  value  of  OBJECT-ITEM-CATEGORY-CODE  would  always  be  MA  (materiel).  The  rest 
represent  ambiguous  knowledge. 


Table  17.  Summary  of  Element  Assessment  Effort  for  Equipment 


Level 

Number  of  Assessments 

Irrelevant 

Elements 

Terminal 

Elements 

Total 

Unique 

Conceptual 

1 

1 

0 

0 

Entity 

14 

14 

0 

0 

State 

58 

58 

1 

38 

Value 

19 

15 

The  EC2IEDM  equipment  area  aligns  to  the  JSIMS  EOM  elasses  listed  in  Table  18.  The 
breadth  of  elasses  refleets  our  praetiee  of  being  willing  to  ehoose  a  JSIMS  EOM  elass  if  it 
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contains  even  one  attribute  to  which  an  LC2IEDM  attribute  might  align  at  the  State  level. 
For  this  reason,  the  superclass  equipment  is  used  often:  if  one  of  its  subclasses  is  used,  then 
its  attributes  equipment_name  and  abstract_id  are  also  used  in  context  to  identify  the  equip¬ 
ment  modeled  by  the  subelass. 


Table  18.  JSIMS  FOM  Classes  Used  in  Aligning  the  Equipment  Area 


Class 

Occurrences 

Class 

Occurrences 

abstract 

3 

equipment.naval sensor 

1 

.land 

1 

.naval weapon system 

1 

.equipment type 

3 

.sensor 

1 

equipment 

5 

.comint 

2 

.airborne sensor 

1 

.elint 

2 

.esm 

2 

.opint 

1 

.iff 

2 

.radint 

2 

.ir 

2 

.sensor deck 

2 

.optical 

2 

platform 

6 

.equipment radiating 

0 

.airbome radar 

1 

.aid 

1 

.gps 

1 

.rf noiseJammer 

1 

LC2IEDM’s  comparative  wealth  of  modeling  eapability  in  the  equipment  area  suggests  it 
would  not  align  well  with  WARSIM,  a  hypothesis  borne  out  by  our  assessment.  We  as¬ 
sessed  14  entities  and  58  attributes.  Figure  32  shows  the  results.  Over  one  third  of  the  at¬ 
tributes  did  not  align  at  all,  and  over  two  thirds  aligned  less  than  50%.  The  overall  degree 
of  alignment  for  the  equipment  area  was  42%. 


o 
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Degree  of  Alignment 

Figure  32.  Results  of  Equipment  Area  Attribute  Alignment  Assessments 

7.3  Environment 


Performing  an  assessment  of  the  “reverse”  alignment  between  the  EC2IEDM  and  TCDM 
models  proved  difficult.  The  EC2IEDM  model  provides  templates,  in  the  form  of  -TYPE 
entities,  from  which  to  create  specific  entity  instances.  FACILITY -TYPE  and  FEATURE_TYPE 
allow  a  modeler  to  instantiate  a  wide  variety  of  entities,  using  the  eategory  eodes 
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(FACILITY-TYPE-CATEGORY-CODE  or  FEATURE-TYPE-CATEGORY-CODE)  to  identify  them.  As  a 
result  the  model  does  not  eontain  a  large  eolleetion  of  “pre-defined”  entities  in  the  form 
of  faeilities  or  features.  The  LC2IEDM  eontains  only  two  FACILITY  entities,  MINEFIELD  and 
BRIDGE.  The  following  seetions  present  an  assessment  of  the  MINEFIELD  entity,  and  of 
eategory  eode-based  mappings. 

It  should  be  noted  that  we  originally  interpreted  (EDCS)  Classifieation  Codes  as  being 
part  of  the  TCDM.  In  faet  this  is  not  always  the  ease.  During  the  review  of  this  doeument, 
we  learned  that  some  of  our  Value-level  TCDM  assessments  use  non-TCDM  eodes.  Un¬ 
fortunately  we  did  not  have  the  resourees  to  revise  the  assessments.  Some  assessments 
may  therefore  have  a  lower  degree  of  alignment  than  indieated.  However,  we  do  not  ex- 
peet  that  the  overall  degree  of  alignment  for  the  Environment  area  would  ehange  signifi- 
eantly  if  we  were  to  re-eonduet  these  assessments. 

7.3.1  Example  Alignment:  Minefield 

The  EC2IEDM  entity  MINEFIELD  was  mapped  to  the  TCDM  feature  MINEFIELD.  The 
EC2IEDM  entity  is  defined  as  “a  FACILITY  that  is  an  area  of  land  or  water  containing 
mines  laid  with  or  without  a  pattern."  The  TCDM  feature  is  defined  as  “an  area  of  land 
or  water  throughout  which  explosive  mines  have  been  laid."  Based  on  the  similarity  of 
these  definitions  and  the  range  of  attributes,  a  100%  degree  of  alignment  was  assigned  for 
this  EC2IEDM  entity.  MINEFIELD  has  five  attributes:  MINEFIELD-ID,  MINEFIELD-SPACING- 
DIMENSION,  MINEFIELD-PATTERN-CODE,  MINEFIELD-PERSISTANCE-CODE,  and  MINEFIELD- 
PURPOSE-CODE. 

Three  of  these  attributes,  MINEFIELD-SPACING-DIMENSION,  MINEFIELD-PATTERN-CODE,  and 
MINEFIELD-PERSISTANCE-CODE,  have  no  eorresponding  attribute  in  the  TCDM.  For  eaeh  of 
these  attributes  an  assigned  and  eomputed  0%  degree  of  alignment  was  reeorded  for  the 
State-level  assessment. 

The  LC2IEDM  MINEFIELD  attribute  MINEFIELD-ID  is  defined  as  "The  FACILITY-ID  of  a  spe¬ 
cific  MINEFIELD  (a  role  name  for  OBJECT-ITEM-ID)."  This  attribute  was  mapped  to  the 
TCDM  attribute  Object  Identification  Number.  Object  Identification  Number  is  defined  as  "unique 
object  identification  number  within  a  dataset."  While  these  definitions  are  not  synony¬ 
mous,  an  eneoding  would  be  possible.  For  this  reason,  a  75%  degree  of  alignment  was 
assigned  for  this  attribute.  Continuing  to  the  Value-level  assessment,  the  data  type  of  eaeh 
attribute  was  evaluated.  The  LC2IEDM  attribute  is  represented  as  a  numerie  value  having 
fifteen  digits.  In  the  TCDM,  the  Object  Identification  Number  can  assume  any  value  in  the 
range  -2147483647  to  2147483647.  This  represents  only  a  vanishingly  small  percentage 
of  the  values  that  can  be  represented  in  the  EC2IEDM,  but  in  practice  it  is  large  enough 
to  represent  any  set  of  values  that  might  be  used.  A  100%  degree  of  alignment  was  as¬ 
signed  for  this  attribute. 

The  EC2IEDM  MINEFIELD-PURPOSE-CODE  is  defined  as  "the  specific  value  that  represents 
or  de-notes  the  intended  function  of  a  specific  MINEFIELD."  MINEFIELD-PURPOSE-CODE 
was  mapped  to  the  TCDM  attribute  Mine  Type  Category.  This  attribute  is  defined  as  "the 
type  of  mine."  A  50%  degree  of  alignment  was  assigned  for  this  attribute.  Continuing  to 
the  Value-level  assessment,  the  data  type  of  each  attribute  was  assessed.  Both  data  types 
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are  enumerations.  The  LC2IEDM  MINEFIELD-PURPOSE-CODE  has  seven  enumerations  in- 
eluding  heavy  taetieal,  light  taetieal,  medium  taetieal,  nuisanee,  phony,  proteetive,  and 
unknown.  The  TCDM  Mine  Type  Category  has  twelve  enumerations  ineluding  sueh  values 
as  Ocean,  Buried,  Ocean,  Bottom,  Mixed,  Anti-Tank,  Anti-Personnel,  Phony/Decoy  and  Unknown.  Only 
two  of  the  seven  LC2IEDM  enumerations,  Phony/Decoy  and  Unknown,  were  mapped  to 
TCDM  enumerations.  Thus,  a  29%  degree  of  alignment  was  eomputed  for  the  EC2IEDM 
attribute  MINEFIELD-PURPOSE-CODE. 

The  results  of  the  State  and  Value-level  assessments  are  shown  in  Table  19.  Performing  a 
roll  up  of  the  eomputed  values  for  the  EC2IEDM  MINEFIELD  faeility,  by  averaging  the 
eomputed  degree  of  alignment  for  the  attributes  of  this  entity  along  with  those  of  its  su¬ 
pertypes  (not  shown),  resulted  in  a  57%  degree  of  alignment  at  the  Entity  level.  No  ad¬ 
justment  faetors  were  applied  in  the  reverse  alignment. 


Table  19.  Degree  of  Alignment  of  Minefield  Attributes 


MINEFIELD  Attribute 

Assigned  Degree 
of  Alignment 

Computed  Degree  of 
Alignment 

MINEFIELD-ID 

75% 

100% 

MINEFIELD-SPACING-DIMENSION 

0% 

0% 

MINEFIELD-PATTERN-CODE 

0% 

0% 

MINEFIELD-PERSISTANCE-CODE 

0% 

0% 

MINEFIELD-PURPOSE-CODE 

50% 

29% 

7.3.2  Example  Alignment:  LC2IEDM  Category  Codes 

Many  of  the  features  and  facilities  found  in  the  EC2IEDM  are  represented  as  category 
codes  within  the  FACILITY-TYPE  or  FEATURE-TYPE  subtypes,  CONTROL-FEATURE-TYPE, 
GEOGRAPHIC-FEATURE-TYPE,  and  METEOROLOGIC-FEATURE-TYPE.  These  category  codes  are 
attributes  of  their  FACILITY-  and  FEATURE-TYPEs.  In  performing  an  alignment  assessment, 
this  portion  of  the  work  deviates  from  the  prescribed  approach.  At  the  Entity  level,  the 
methodology  dictates  that  a  single  EC2IEDM  entity  is  mapped  to  zero  or  more  TCDM 
features.  At  the  State  level,  a  single  EC2IEDM  attribute  is  mapped  to  zero  or  more 
TCDM  attributes.  Eor  the  majority  of  the  features  and  facilities  in  the  EC2IEDM  this  was 
not  possible.  Instead,  EC2IEDM  attributes,  the  category  codes  for  the  features  and  facili¬ 
ties,  were  mapped  to  TCDM  features. 

Using  this  approach  we  performed  a  pseudo-mapping  for  all  the  features  and  facilities  in 
the  EC2IEDM.  The  results  of  that  mapping  are  shown  in  Table  20.  Many  of  the  mappings 
were  exact:  EC2IEDM  GEOGRAPHIC-FEATURE-TYPE  LAK  (Eake/pond)  was  mapped  to 
TCDM  feature  Lake/pond.  Some  of  the  mappings  were  less  exact:  EC2IEDM  GEOGRAPHIC- 
FEATURE-TYPE  MTN  (Mountain)  was  mapped  to  TCDM  feature  Mountainous  Region. 
EC2IEDM  FACILITY-TYPE  OEM  (Cemetery/graveyard/burial  ground)  was  mapped  to  both 
TCDM  feature  Cemetery  and  TCDM  feature  Burial  Grounds.  In  some  cases  precision  would 
be  lost  though  the  mapping:  EC2IEDM  FACILITY-TYPEs  FORTLN  (Eortified  Eine),  FORTPT 
(Eortified  Point),  and  FRTARE  (Eortified  Area)  all  mapped  to  the  TCDM  feature  Fortification. 
An  adjustment  factor  would  need  to  be  applied  to  any  assigned  degree  of  alignment  to 
account  for  this.  In  other  cases,  additional  information  would  be  needed  to  perform  a  cor¬ 
rect  mapping:  does  EC2IEDM  FACILITY-TYPE  INDINS  (Industrial  Installation)  map  to 
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TCDM  feature  Industrial  Complex  (Heavy),  Industrial  Complex  (Light),  Industrial  Works,  or  Industrial 
Building? 


Table  20.  Pseudo-Mapping  Results 


LC2IEDM  Category  Code 

%  Mapped  to  the  TCDM 

FACILITY-TYPE  CATEGORY  CODE 

51% 

CONTROL-FEATURE-TYPE  CATEGORY  CODE 

5% 

GEOGRAPHIC-FEATURE-TYPE  CATEGORY  CODE 

83% 

METEOROLOGIC-FEATURE-TYPE  CATEGORY  CODE 

0% 

Most  striking  in  the  results  tabulated  below  is  the  degree  of  alignment  estimated  for  the 
CONTROL-FEATURE-TYPE  eategory  eodes.  The  LC2IEDM  provides  a  mueh  rieher  range  of 
eontrol  features  than  does  the  TCDM.  The  faet  that  no  mapping  was  possible  between  the 
LC2IEDM  METEOROLOGIC-FEATURE-TYPE  eategory  eodes  and  features  in  the  TCDM  was 
expeeted.  The  TCDM  purposefully  omitted  all  meteorologieal  information  in  this  revi¬ 
sion. 

Eliminating  from  eonsideration  the  EC2IEDM  METEOROLOGIC-FEATURE-TYPE,  the  overall 
degree  of  alignment  between  the  EC2IEDM  eodes  and  the  TCDM  features  is  46%. 
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8.  Recommendations 


The  analysis  has  led  to  reeommendations  on  what  steps  that  may  be  taken  to  improve  the 
alignment  of  WARSIM  and  the  LC2IEDM.  This  seetion  presents  these  reeommendations. 
Reeommendations  are  stated  as  eategories  of  ehange,  rather  than  as  suggestions  for 
ehanges  to  speeifie  attributes  or  domains.  The  alignment  assessment  databases,  and  to  a 
lesser  extent  Appendiees  B-D,  ean  be  used  to  identify  exaetly  whieh  areas  of  the  models 
must  ehange  to  inerease  alignment. 

These  reeommendations  are  derived  from  a  study  of  alignment  between  the  LC2IEDM 
and  WARSIM,  but  they  have  broader  implieations.  In  our  experienee,  they  identify  gen¬ 
eral  problems  that  C4ISR  systems  have  supporting  M&S  data,  and  that  M&S  systems 
have  supporting  C4ISR  data.  Any  program  that  needs  C4ISR/M&S  interoperability  must 
address  the  problems  raised  in  this  report.  The  following  reeommendations  are  one  ap- 
proaeh  to  solving  these  problems. 

8.1  LC2IEDM  Enhancements 

Several  reeommendations  ean  be  made  for  enhaneements  to  the  EC2IEDM.  In  ereating 
these  reeommendations,  the  study  evaluated  what  ehanges  would  be  benefieial  for  the 
general  elass  of  simulations  to  whieh  WARSIM  belongs.  Thus,  the  ehanges  reeommended 
were  not  speeifie  to  WARSIM,  but  would  support  requirements  from  the  larger  elass  of 
eonstruetive  simulations. 

8.1.1  Scope 

Suggested  enhaneements  to  the  EC2IEDM  are  organized  by  the  three  assessment  areas: 
Unit,  Equipment,  and  Environment. 

8.1.2  Recommended  Changes  for  Simulation  Unit  Data 

The  enumerations  for  the  types  of  units  in  EC2IEDM  need  to  be  expanded  to  refleet  more 
elosely  the  data  requirements  in  simulations.  In  addition,  struetures  for  handling  informa¬ 
tion  exehange  requirements,  sueh  as  those  that  exist  in  other  large  standardized  models 
(e.g.,  the  C4ISR  Core  Arehiteeture  Data  Model  (CADM))  may  be  needed  to  handle  as- 
peets  sueh  as  the  frequeney  of  the  messaging  among  nodes,  the  timeliness  of  the  data,  its 
temporal  validity,  ete.  The  same  is  true  for  those  simulation  data  requirements  that  ex¬ 
press  assessments  of  the  unit  with  respeet  to  its  aetivities,  e.g.,  mission  effeetiveness  and 
morale,  that  eurrently  eannot  be  speeified  other  than  as  text,  e.g.,  via  the  EC2IEDM  strue- 
ture  CONTEXT.  Einally,  it  may  be  neeessary  in  EC2IEDM  to  provide  enumerations  that 
refleet  assessments  in  a  quantitative  form  rather  than  in  general  terms,  e.g.,  pereentage  of 
eoneealment  of  a  unit,  as  opposed  to  the  general  aetivity  of  hiding  as  part  of  an  aetion 
speeified  for  that  military  unit. 
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8.1.3  Recommended  Changes  for  Simulation  Equipment  Data 

As  in  Section  8.1.2,  there  is  a  need  for  enlarging  the  enumerations  in  LC21EDM  to  handle 
the  numerous  equipment  types  specified  in  the  simulation  model,  but,  perhaps  more  im¬ 
portantly,  for  introducing  the  concept  of  PLATFORM  as  an  explicit  subtype  of  MATERIEL- 
TYPE  to  enable  a  closer  alignment  between  the  two  models.  The  need  in  LC21EDM  for 
quantitative  enumerations,  e.g.,  as  percentages,  is  also  present  here.  The  motion  of  units 
in  EC21EDM  is  primarily  along  2-dimensional  paths.  The  model  does  not  support  multi¬ 
ple  geodetic  reference  models,  expecting  every  entry  to  be  referenced  to  the  WGS-84 
standard.  Allowing  for  different  coordinate  systems  of  reference  and  for  3 -dimensional 
paths  would  permit  the  handling  of  spatial  trajectories,  orbits,  etc.,  as  well  as  direct  up¬ 
load  and  download  of  coordinates  without  intermediate  transformations. 

In  fairness  to  the  EC21EDM  it  should  be  noted  that  the  domain  value  level  specification 
in  WARSIM  elements  published  to  the  JSIMS  EOM  were  not  sufficiently  explicit  as  to 
allow  unambiguous  interpretation  of  the  meanings  of  those  values. 

8.1.4  Recommended  Changes  for  WARSIM  Environment  Data 

What  has  been  said  with  respect  to  the  Unit  and  Equipment  areas  in  WARSIM  applies 
equally  so  to  the  Environment  area,  namely,  that  a  substantial  expansion  of  the  enumera¬ 
tions  in  EC21EDM  is  needed  to  better  support  the  data  requirements  of  the  simulation.  On 
the  other  hand,  it  is  not  clear  from  the  data  provided  in  the  TCDM  whether  all  the  classes 
are  primarily  used  as  map  overlays,  and,  therefore,  ought  to  be  treated  simply  as  instances 
of  the  EC21EDM  entity  EEATURE-TYPE,  or  whether  in  fact  those  classes  that  one  nor¬ 
mally  view  as  instances  of  facilities  or  equipment  are  in  fact  used  as  such  in  the  simula¬ 
tion.  There  is,  therefore,  in  the  current  alignment  assessment  a  certain  amount  of  uncer¬ 
tainty.  While  some  classes  in  WARSIM  correspond  to  enumerations  in  FACILITY-TYPE  in 
EC21EDM  and  others  appear  to  map  cleanly  to  enumerations  in  FEATURE-TYPE. not  all 
cases  are  easily  decided.  Thus,  we  encourage  the  TCDM  developers  to  draw  a  stronger 
distinction  between  TCDM  features  that  are  intended  just  to  support  map  overlays  and 
those  that  are  treated  as  genuine  facilities. 

East  but  not  least,  there  is  a  need  to  enlarge  the  set  of  attributes  in  EC21EDM  that  charac¬ 
terizes  either  a  FEATURE  or  a  FACILITY  so  that  all  of  the  86  attributes  that  TCDM  specifies 
for  its  environment  classes  can  be  captured  in  EC21EDM,  as  opposed  to  only  41  cur¬ 
rently. 

8.2  Modeling  And  Simulation  Recommendations 

WARSIM  was  found  to  cover  only  61%  of  the  EC21EDM  Unit  area  data  elements,  and 
70%  of  its  Equipment  area  data  elements.  This  indicates  that  WARSIM  (as  represented  by 
its  elements  of  the  JSIMS  EOM)  has  substantial  limitations  in  being  able  to  represent  in¬ 
formation  that  is  important  to  effective  C2  operations.  Some  of  these  limitations  are  a  re¬ 
flection  of  using  an  HEA  EOM  as  the  model  source,  since  a  EOM  cannot  represent  class 
associations  (such  as  unit  command  structure)  except  for  class  inheritance  hierarchies, 
even  though  the  underlying  simulation  may  support  them.  Thus,  it  would  be  helpful  in 
assessing  a  simulation’s  modeling  capabilities  and  its  potential  for  effective  data  interop- 
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erability,  to  have  additional  sources  of  modeling  information.  Such  information  could  be 
provided  either  by  maintaining  current  design  and  implementation  models  in  addition  to  a 
FOM,  or  by  supplementing  a  FOM  with  just  the  neglected  associational  information. 

Even  neglecting  the  absence  of  association  information,  the  WARSIM  data  elements  fell 
far  short  of  capturing  all  the  types  of  data  used  in  C2  interchanges.  The  mismatches  be¬ 
tween  the  models  examined  indicates  that  Army  M&S  systems  may  benefit  from  a  refer¬ 
ence  object  model  which  identifies  all  relevant  C4I  data  elements  within  the  context  of  a 
structure  that  would  be  applicable  to  M&S  design.  Development  of  such  a  model  is  a 
natural  next  step. 
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Illinois  Institute  of  Technology 
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Appendix  A.  Notation 


This  appendix  provides  a  brief  deseription  of  the  IDEFIX  and  UML  notation  used  in  this 
report.  It  is  intended  for  referenee  and  not  as  a  tutorial.  The  reader  should  eonsult 
[NIST  1993]  for  more  details  on  the  IDEFIX,  and  [BJRR  1998]  for  more  details  on 
UME. 

Some  figures  use  shading  (or,  in  the  electronie  version,  eolor).  Shading  in  diagrams  has 
no  semanties  in  this  doeument.  It  is  used  to  draw  the  reader’s  attention  to  speeifie  ele¬ 
ments  of  a  figure  or  table.  However,  in  some  tables  of  Appendix  F,  shading  of  rows  is 
used  to  distinguish  assessments  of  entity  alignments  from  separate  assessments  of  their 
attributes  on  subsequent  rows  (as  deseribed  there). 

A.l  IDEFIX  Notation 

IDEFIX  (ICAM  Definition  1  Extended  [NIST  1993])  is  a  speeifieation  for  modeling  enti¬ 
ties,  attributes,  and  their  relationships.  The  speeifieation  includes  a  standard  graphical 
notation.  The  following  is  a  brief  description  of  the  components  of  that  notation  that  ap¬ 
pear  in  this  report. 

A  box,  with  square  or  rounded  comers,  denotes  an  entity.  If  the  box  has  square  comers,  it 
is  an  independent  entity,  i.e.,  an  entity  that  depends  on  no  other  for  its  definition.  If  the 
box  has  rounded  corners,  it  is  a  dependent  entity.  Figure  A-1  shows  the  distinction  be¬ 
tween  dependent  and  independent  entities. 

Relationships  between  entities  are  depicted  using  lines  drawn  between  the  entities.  If  the 
line  is  solid,  the  relationship  is  an  identifying  relationship.  If  the  line  is  dashed,  the  rela¬ 
tionship  is  a  non-identifying  relationship.  The  presence  or  absence  of  black  circle  at  the 


Independent  entity  Relationship  name 

relates-to  *  ENTITY_2 


,  Dependent  entity 


ENTITY_1 

' - - 

•  One-to-many  identifying  relationship 
(One  ENTITY_1,  many  ENTITY_2) 


\ 


ENTITY  3 


■One-to-many  nonidentifying  relationship 
(One  ENTITY_1,  many  ENTITY_3) 

ENTITY  4 


Many-to-many  relationship 

Figure  A-1.  IDEFIX  Entity  and  Relationship  Notation 
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end  of  the  line  speeifies  a  relationship’s  eardinality.  One  instanee  of  an  entity  on  an  end 
that  has  no  eirele  partieipates  in  a  relationship.  Zero  or  more  instanees  of  an  entity  on  an 
end  with  a  eirele  partieipate  in  a  relationship.  A  diamond  on  the  end  of  the  line  for  a  non¬ 
identifying  relationship  means  an  instanee  of  the  entity  at  the  “many”  end  need  not  refer- 
enee  an  instanee  at  the  “one”  end.  Figure  A-1  shows  examples  of  how  these  relationships 
appear. 

Some  relationships  are  labeled,  sueh  as  relationship  labeled  “relates-to”  in  Figure  A-1. 
The  label  is  optional.  It  has  no  semantie  meaning;  it  merely  serves  to  elarify  the  relation¬ 
ship’s  nature. 

One  entity  may  be  a  subtype  of  another.  A  subtype  relationship  is  indieated  by  a  eirele 
with  one  or  two  lines  beneath  it.  A  line  from  the  top  of  this  glyph  eonneets  to  an  entity; 
that  entity  is  the  supertype.  One  or  more  lines  from  the  bottom  of  this  glyph  eaeh  eonneet 
to  a  single  entity;  that  entity  is  a  subtype.  Figure  A-2  shows  both  eomplete  and  ineom- 
plete  subtype  relationships. 

A  subtype  relationship  has  a  diseriminator,  whieh  is  an  attribute  from  the  supertype.  The 
value  of  a  diseriminator  identifies  the  type  of  a  subtype.  If  this  attribute  speeifies  all  pos¬ 
sible  subtypes,  the  subtype  relationship  is  complete  and  its  glyph  eontains  a  double  line 
(as  shown  in  Figure  A-2).  If  the  attribute  only  deseribes  a  proper  subset  of  possible  sub- 
types,  the  subtype  relationship  is  incomplete  and  its  glyph  eontains  a  single  line.  Ordinar¬ 
ily,  an  IDEFIX  diagram  view  with  a  eomplete  subtype  relation  will  display  all  of  the  sub- 
type  entities.  However,  in  our  presentation  of  partieular  examples,  we  do  not  always  dis¬ 
play  all  subtype  entities  due  to  spaee  limitations  and  our  foeus  on  one  or  more  entities  of 
interest  in  an  example. 


IDEFIX  diagrams  may  depiet  or  omit  attributes.  The  entities  depleted  in  Figure  A-1  and 
Figure  A-2  have  omitted  attributes.  An  IDEFIX  diagram  that  depiets  attributes  plaees  the 
entity  name  atop  the  box.  Within  the  box  are  attributes.  Eaeh  line  shows  information  on  a 
single  attribute.  At  a  minimum,  the  line  shows  the  attribute’s  name.  It  may  also  show  the 
attribute’s  data  type  (after  a  eolon)  and  that  an  attribute  is  a  foreign  key  (indieated  by  an 
“(EK)”  sulfix).  Attributes  in  the  top  sub-box  are  primary  keys.  Eigure  A-3  shows  exam- 
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pies  of  entities  displaying  attributes;  the  entities  are  drawn  from  Figure  A-1  and  have  for¬ 
eign  keys  aeeording  to  the  relationships  from  that  figure. 

ENTITY  2 


Figure  A-3.  IDEFIX  Display  of  Attributes 

A.2  UML  Notation 

UML  (Unified  Modeling  Language  [BJRR  1998])  is  a  language  for  graphically  depicting 
many  software  development  entities.  Part  of  UML  includes  a  model  for  depicting  classes 
and  their  associations.  This  part  of  the  model  has  been  used  in  this  report. 

A  UML  class  is  depicted  as  a  rectangular  box.  The  name  of  the  class  appears  inside  the 
box.  The  left  side  of  Figure  A-4  shows  how  a  class  is  depicted  when  its  attributes  are 
omitted. 

A  UML  diagram  may  show  just  a  class’s  name.  It  may  also  show  the  class’s  attributes  and 
Class  without  attributes  Class  with  attributes 


ClassName 


ClassName 


attr1:  type1 
attr2:  type2 


Figure  A-4.  UML  Notation  for  Depicting  Classes 
methods,  in  which  case  the  box  is  divided  into  three  vertically  stacked  boxes.  The  top  box 
contains  the  class’s  name.  The  middle  box  contains  the  class’s  attributes.  The  bottom  box 
contains  the  class’s  methods.  The  right  side  of  Figure  A-4  shows  how  a  class’s  attributes, 
including  each  attribute’s  data  type,  are  depicted.  Because  the  JSIMS  FOM  does  not  as¬ 
sociate  methods  with  classes,  figures  in  this  report  show  the  bottom  as  empty. 


One  class  may  be  a  superclass  of  another.  The  first  class  is  said  to  generalize  the  second 
class.  Generalization  is  depicted  by  an  upward  arrow.  See  Figure  A-5. 


Figure  A-5.  UML  Notation  for  Depicting  Generalization  Relationships 
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Appendix  B.  Unit  Alignment  Assessments 


This  appendix  presents  the  Entity-level  assessments  related  to  the  Unit  coneept.  It  is  di¬ 
vided  into  two  seetions.  Section  B.l  gives  the  assessments  for  the  degree  to  which  WAR- 
SIM  unit-related  classes  can  be  represented  in  the  LC2IEDM.  Section  B.2  gives  the  as¬ 
sessments  for  the  degree  to  which  LC2IEDM  unit-related  entities  can  be  represented  in 
WARSIM. 

Each  section  consists  of  a  table.  This  table  is  broken  into  the  individual  Entity-level 
alignment  assessments.  Each  assessment  contains: 

•  The  assessment’s  signature,  of  the  form: 

element  {e^,e2,...,e^] 

The  interpretation  is  that  element  in  one  model  aligns  to,  i.e.,  can  be  represented 
by,  the  set  of  elements  from  the  other  model. 

•  Notes  made  by  assessors  during  the  alignment. 

•  The  computed  degree  of  alignment.  This  value  has  been  computed  from  lower- 
level  assessments,  using  the  formulas  discussed  in  the  body  of  this  study. 

•  Indications  if  the  assessment  is  not  applicable  or  terminal. 

B.l  WARSIM^LC2IEDM  Alignment 

Table  B-1.  Unit  Assessment  Summaries:  WARSIM^LC2IEDM  Alignment 

org^lORGANISATION} 

Notes  A  JSIMS  org  class  aligns  to  an  LC2IEDM  ORGANISATION  . 

6  items  map  to  ORGANIZATION  (236,  237,  238,  296,  150036, 
150102) 

We  can  distinguish  a  simple  org  object  (whose  WARSIM 
subclass  is  not  assigned)  from  all  other  WARSIM  unit  class 
types  -  org. land. unit,  org_perceived_unit_c  and 
extended_perceived_unit_c  -  using  the  ORGANISATION-TYPE- 
CATEGORY-CODE  which  is  set  to  “UN"  for  units.  A  simple  org 
object  can  be  distinguished  from  org. land  and  its  subclasses 
because  they  are  all  either  Units  with  a  UNIT-TYPE-SERVICE- 
CODE  set  to  “A"  for  Army  or  they  have  an  ORGANISATION  as¬ 
sociation  to  such  a  unit.  The  LC2IEDM  OBJECT-TYPE-NAME 
might  also  be  used  to  support  this  distinction,  although 
there  are  no  standard  LC2IEDM  names  for  such  WARSIM 
classes 

Computed  Degree  of  Alignment:  84 _ 
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org.land^lCAPABILITY,  COMBAT-UNIT-TYPE,  CONVOY,  FIRE-CAPABILITY,  HOLDING,  MATERIEL-STATUS, 
OBJECT-ITEM,  ORGANISATION-ORGANISATION-ASSOCIATION,  ORGANISATION-STATUS,  PERSON-STATUS, 
SUPPORT-UNIT-TYPE,  UNIT-TYPE} 

Notes  6  items  can  map  to  land  (Army)  ORGANISATIONS  (236,  238, 

296,  150044,  150036,  150102). 

We  can  distinguish  a  simple  org.land  object  (whose  WARSIM 
subclass  is  not  assigned)  from  an  org.land. unit, 
org_perceived_unit_c  and  extended_perceived_unit_c  -  since  its 
ORGANISATION-TYPE-CATEGORY-CODE  will  not  be  “UN"  for  unit. 
The  org_perceived_unit_c  and  extended_perceived_unit_c  WARIM 
objects  can  also  be  distinguished  by  the  absence  of  a 
REPORTING-DATA-REPORTING-ORGANISATION-ID  set  to  a  unique 
ID  chosen  to  distinguish  ground  truth.  Org.land  data  is  con¬ 
sidered  WARSIM  ground  truth,  while  perceived  data  is 
not.  But,  we  don't  see  a  way  to  distinguish 
org.land.equip_group  and  org.land.supply_cache  from  a  simple 
org.land  object.  Hence,  there  is  an  adjustment  factor  (50  + 
50/3  =  67).  Although  the  LC2IEDM  OBJECT-TYPE-NAME  can 
be  used  to  support  this  distinction,  there  are  no  standard 
LC2IEDM  names  for  such  WARSIM  classes  . 

JSIMS  Notes:  For  Unit  and  Equipment  areas 

LC2IEDM  Notes:  Used  to  associate  an  org.land  object  with  an  Army  organiza¬ 

tion  if  it  is  not  identified  as  a  unit  (which  contains  the  UNIT- 
TYPE-SERVICE-CODE). 

Computed  Degree  of  Alignment:  54 _ 

org.land.unit^jORGANISATION,  UNIT,  OBJECT-ITEM,  OBJECT-ITEM-TYPE,  OBJECT-TYPE,  OBJECT-TYPE- 
CAPABILITY-NORM,  OBJECT-ITEM-CAPABILITY,  HOLDING,  OBJECT-ITEM-STATUS,  ORGANISATION-STATUS 
ORGANISATION-ORGANISATION-ASSOCIATION,  ACTION-TASK,  ACTION-TASK-STATUS,  ACTION,  ACTION- 
RULE-OF-ENGAGEMENT,  RULE-OF-ENGAGEMENT,  ACTION-OBJECTIVE,  ACTION-OBJECTIVE-TYPE,  ACTION- 
OBJECTIVE-ITEM,  TARGET,  ACTION-RESOURCE,  ACTION-RESOURCE-ITEM,  ORGANISATION- 
ORGANISATION-TYPE-ESTABLISHMENT,  ORGANISATION-TYPE-ESTABLIISHMENT,  ORGANISATION-TYPE- 
ESTABLIISHMENT-MATERIEL-TYPE-DETAIL,  ORGANISATION-TYPE-ESTABLIISHMENT-PERSON-TYPE-DETAIL, 
MATERIEL-TYPE,  EQUIPMENT-TYPE,  UNIT-TYPE,  ORGANISATION-TYPE,  PERSON-TYPE,  ORGANISATION- 
CONTROL-FEATURE-ASSOCIATION,  CONTROL-FEATURE,  FEATURE,  FEATURE-TYPE,  CONTROL-FEATURE- 
TYPE,  FEATURE-LOCATION,  LOCATION,  SURFACE,  POINT,  MATERIEL-POINT,  ORGANISATION-POINT,  OR- 
GANISATION-MATERIEL-ASSOCIATION,  REPORTING-DATA,  PERSON} 

Notes  4  items  map  to  UNIT  (299,  150044,  150036,  150102). 

Two  other  types  of  units  —  org_perceived_unit_c  and 
extended_perceived_unit_c  —  can  be  distinguished  by  the  ab¬ 
sence  of  a  REPORTING-DATA-REPORTING-ORGANISATION-ID  set 
to  a  unique  ID  chosen  to  distinguish  ground  truth.  Data  in 
org.land. unit  is  interpreted  to  be  WARSIM  ground  truth, 
unlike  the  merely  perceived  units.  The  LC2IEDM  OBJECT- 
TYPE-NAME  can  be  used  to  support  this  distinction,  although 
there  are  no  standard  LC2IEDM  names  for  such  WARSIM 
classes  . 

LC2IEDM  Notes:  Some  JSIMS  units  are  more  general  than  LC2IEDM  UNITs. 

Therefore  this  parent  entity  is  needed  for  some  mappings. 
LC2IEDM  UNITs  appear  to  be  more  narrowly  defined  than 
JSIMS  units. 

Computed  Degree  of  Alignment:  46 _ 
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B.2  LC2IEDM^WARSIM  Alignment 

Table  B-2.  Unit  Alignment  Summaries:  LC2IEDM^WARSIM  Alignment 

COMBAT-UNIT-TYPE^{org.land} 

Notes  The  org.land  class  has  an  attribute,  type,  with  values  that 

align  at  least  in  part  to  the  various  codes  specifiable  by 
attributes  of  COMBAT-UNIT-TYPE. 

LC21EDM  Notes:  From  the  Unit  view. 

Computed  Degree  of  Alignment:  56 _ 

HEADQUARTERS-UNIT-TYPE^{org.land} 

Notes  The  org.land  class  has  an  attribute,  type,  with  values  that 

align  at  least  in  part  to  the  various  codes  specifiable  by 
attributes  of  HEADQUARTERS-UNIT-TYPE. 

LC21EDM  Notes:  From  the  Unit  view. 

Computed  Degree  of  Alignment:  55 _ 

OBJECT-ITEM^{org} 

Notes  Within  the  context  of  modeling  a  UNIT,  the  important  at¬ 

tribute  is  OBJECT-ITEM-NAME.  The  org_name  attribute  of  the 
org  class  models  a  name. 

LC21EDM  Notes:  From  the  Unit  view. 

Computed  Degree  of  Alignment:  100 _ 

OBJECT-ITEM-TYPE^O 

LC21EDM  Notes:  From  the  Unit  view. 

Computed  Degree  of  Alignment:  25 _ 

OBJECT-TYPE^Iorg.land.unit} 

Notes  JSIMS  does  not  have  an  attribute  that  represents  nation¬ 

ality  using  standard  designators  as  the  LC21EDM  does. 

The  intent  attribute  of  the  org. land. unit  class  might  capture  the 
OBJECT-TYPE-NAME  attribute  —  although  that  one  was  also  to 
be  used  for  UNIT-TYPE  attributes. 

LC21EDM  Notes:  From  the  Unit  view. 

Computed  Degree  of  Alignment:  50 _ 

ORGANISATION^!} 

Notes  1  don't  think  JSIMS  has  any  attributes  that  can  model  a 

nickname. 

LC21EDM  Notes:  From  the  Unit  view. 

The  principal  attribute  to  model  is  the  nickname. 

Computed  Degree  of  Alignment:  83 _ 
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ORGANISATION-ORGANISATION-ASSOCIATION^{org.land} 

Notes  The  org.land  class  has  some  attributes  that  can  specify  rela¬ 

tionships  to  other  organizations. 

LC2IEDM  Notes:  From  the  Unit  view. 

Computed  Degree  of  Alignment:  50 _ 

ORGANISATION-ORGANISATION-TYPE-ESTABLISHMENT^O 

Notes  I  don't  think  this  entity  aligns.  JSIMS  models  concrete  as¬ 

sociations  between  organizations,  not  allocations  of  organi¬ 
zation  types. 

LC2IEDM  Notes:  From  the  Unit  view. 

Computed  Degree  of  Alignment:  0 

Assessment  is  terminal. _ 

ORGANISATION-TYPE^O 

Notes  This  one  aligns  by  default  —  its  attributes  are  fixed. 

LC2IEDM  Notes:  From  the  Unit  view. 

Computed  Degree  of  Alignment:  64 _ 

ORGANISATION-TYPE-ESTABLISHMENT^O 

Notes  I  don't  think  this  entity  aligns.  JSIMS  models  concrete  as¬ 

sociations  between  organizations,  not  allocations  of  organi¬ 
zation  types. 

LC2IEDM  Notes:  From  the  Unit  view. 

Computed  Degree  of  Alignment:  0 

Assessment  is  terminal. _ 

ORGANISATION-TYPE-ESTABLISHMENT-ORGANISATION-TYPE-DETAIL^O 

Notes  I  don't  think  this  entity  aligns.  JSIMS  models  concrete  as¬ 

sociations  between  organizations,  not  allocations  of  organi¬ 
zation  types. 

LC2IEDM  Notes:  From  the  Unit  view. 

Computed  Degree  of  Alignment:  0 

Assessment  is  terminal. _ 

SUPPORT-UNIT-TYPE^{org.land} 

Notes 

LC2IEDM  Notes: 

Computed  Degree  of  Alignment _ 

UNIT^{org,org. land. unit} 

Notes  The  JSIMS  org.land. unit  class  seems  to  most  closely  capture 

the  intent  of  a  UNIT.  The  org  class  has  the  equivalent  con¬ 
cept  of  an  ID. 

LC2IEDM  Notes:  From  the  Unit  view. 

Computed  Degree  of  Alignment:  88 _ 


The  org.land  class  has  an  attribute,  type,  with  values  that 
align  at  least  in  part  to  the  various  codes  specifiable  by 
attributes  of  SUPPORT-UNIT-TYPE. 

From  the  Unit  view. 

:  59 
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UNIT-TYPE^{org. land, org. land. unit} 
Notes 

Two  JSIMS  classes  —  org. land. unit  and  org.land  —  have  attrib¬ 
utes  that  can  describe  a  unit's  type.  The  relevant  attribute 
of  org. land. unit  is  an  arbitrary  string.  This  attribute  could  be 
used  to  model  any  of  the  attributes  of  UNIT  —  or  all,  I  sup¬ 
pose,  if  one  wanted  to  create  some  complex  encoding 
scheme. 

The  relevant  attribute  of  org.land  enumerates  a  set  of  possi¬ 
ble  unit  types.  It  remains  to  be  seen  if  these  unit  types 
overlap  the  unit  types  expressed  by  attributes  of  UNIT-TYPE. 

LC2IEDM  Notes: 

From  the  Unit  view. 

This  entity  describes  more  than  just  a  unit's  type.  Its  at¬ 
tributes  also  characterize  size,  service,  and  mobility, 
among  other  things. 

JSIMS  Notes: 

The  “unitjype"  attribute  may  be  relevant. 

Actually  this  is  the  “type”  attribute 

The  “intenf’  attribute  may  be  able  to  capture  information 
equivalent  to  that  of  a  unit  type. 

Computed  Degree  of  Alignment: 

56 
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Appendix  C.  Equipment  Alignment  Assessments 


This  appendix  presents  the  Entity-level  assessments  related  to  the  Equipment  eoneept.  It 
is  divided  into  two  seetions.  SeetionC.l  gives  the  assessments  for  the  degree  to  whieh 
WARSIM  materiel-related  elasses  ean  be  represented  in  the  EC2IEDM.  Seetion  C.2  gives 
the  assessments  for  the  degree  to  whieh  EC2IEDM  equipment-related  entities  ean  be  rep¬ 
resented  in  WARSIM. 

Eaeh  seetion  eonsists  of  a  table.  This  table  is  broken  into  the  individual  Entity-level 
alignment  assessments.  Eaeh  assessment  eontains: 

•  The  assessment’s  signature,  of  the  form: 

element  {e^,e2,...,e^] 

The  interpretation  is  that  element  in  one  model  aligns  to,  i.e.,  ean  be  represented 
by,  the  set  of  elements  from  the  other  model. 

•  Any  notes  made  by  assessors  during  the  alignment. 

•  The  eomputed  degree  of  alignment.  This  value  has  been  eomputed  from  lower- 
level  assessments,  using  the  formulas  diseussed  in  the  body  of  this  study. 

•  Indieations  if  the  assessment  is  not  applieable  or  terminal. 

C.l  WARSIM^LC2IEDM  Alignment 

Table  C-1.  Materiel  Alignment  Summaries:  WARSIM^LC2IEDM  Alignment 

abstract^lCAPABILITY} 

Computed  Degree  of  Alignment: 

88 _ 

abstract.land^{EQUIPMENT-TYPE,  ORGANISATION-TYPE,  SURVEILLANCE-CAPABILITY,  UNIT-TYPE} 

Computed  Degree  of  Alignment:  86 _ 

abstract.land.equipment_type^{CAPABILITY,  EQUIPMENT-TYPE,  OBJECT-TYPE,  STORAGE-CAPABILITY} 

Notes  3  items  map  to  EQUIPMENT-TYPE  (only)  (only)  (301,  303, 

150099). 

Computed  Degree  of  Alignment:  57 _ 

abstract.land.personneljype^h 

Computed  Degree  of  Alignment:  82 _ 

abstract.land.rotary_wing_type^{CAPABILITY,  EQUIPMENT-TYPE,  OBJECT-TYPE,  STORAGE-CAPABILITY} 
Notes  3  items  map  to  EQUIPMENT-TYPE  (only)  (only)  (301,  303, 

150099). 

LC2IEDM  Notes:  The  EQUIPMENT-TYPE-CATEGORY-CODE  attribute  has  a  value 

AIRRW  for  modeling  rotary  wing  aircraft. 

Computed  Degree  of  Alignment:  57 _ 
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org^{ORGANISATION} 

Notes 


A  JSIMS  org  class  aligns  to  an  LC2IEDM  ORGANISATION  . 

6  items  map  to  ORGANIZATION  (236,  237,  238,  296,  150036, 
150102) 

We  can  distinguish  a  simple  org  object  (whose  WARSIM 
subclass  is  not  assigned)  from  all  other  WARSIM  unit  class 
types  -  org. land. unit,  org_perceived_unit_c  and 
extended_perceived_unit_c  -  using  the  ORGANISATION-TYPE- 
CATEGORY-CODE  which  is  set  to  “UN"  for  units.  A  simple  org 
object  can  be  distinguished  from  org. land  and  its  subclasses 
because  they  are  all  either  Units  with  a  UNIT-TYPE-SERVICE- 
CODE  set  to  “A"  for  Army  or  they  have  an  ORGANISATION  as¬ 
sociation  to  such  a  unit.  The  LC2IEDM  OBJECT-TYPE-NAME 
might  also  be  used  to  support  this  distinction,  although 
there  are  no  standard  LC2IEDM  names  for  such  WARSIM 
classes 

Computed  Degree  of  Alignment:  82 _ 

org.land^jCAPABILITY,  COMBAT-UNIT-TYPE,  CONVOY,  FIRE-CAPABILITY,  HOLDING,  MATERIEL-STATUS, 

OBJECT-ITEM,  ORGANISATION-ORGANISATION-ASSOCIATION,  ORGANISATION-STATUS,  PERSON-STATUS, 

SUPPORT-UNIT-TYPE,  UNIT-TYPE} 

Notes  6  items  can  map  to  land  (Army)  ORGANISATIONS  (236,  238, 

296, 150044,  150036,  150102)  . 

We  can  distinguish  a  simple  org. land  object  (whose  WARSIM 
subclass  is  not  assigned)  from  an  org. land. unit, 
org_perceived_unit_c  and  extended_perceived_unit_c  -  since  its 
ORGANISATION-TYPE-CATEGORY-CODE  will  not  be  “UN"  for  unit. 
The  org_perceived_unit_c  and  extended_perceived_unit_c  WARIM 
objects  can  also  be  distinguished  by  the  absence  of  a 
REPORTING-DATA-REPORTING-ORGANISATION-ID  set  to  a  unique 
ID  chosen  to  distinguish  ground  truth.  Org. land  data  is  con¬ 
sidered  WARSIM  ground  truth,  while  perceived  data  is 
not.  But,  we  don't  see  a  way  to  distinguish 
org.land.equip_group  and  org.land.supply_cache  from  a  simple 
org. land  object.  Hence,  there  is  an  adjustment  factor  (50  + 
50/3  =  67).  Although  the  LC2IEDM  OBJECT-TYPE-NAME  can 
be  used  to  support  this  distinction,  there  are  no  standard 
LC2IEDM  names  for  such  WARSIM  classes  . 

JSIMS  Notes:  For  Unit  and  Equipment  areas 

LC2IEDM  Notes:  Used  to  associate  an  org. land  object  with  an  Army  organiza¬ 

tion  if  it  is  not  identified  as  a  UNIT  (which  contains  the  UNIT- 
TYPE-SERVICE-CODE). 

Computed  Degree  of  Alignment:  54 _ 
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org.land.equip_group^{HOLDING,  MATERIEL,  MATERIEL-TYPE,  OBJECT-ITEM,  OBJECT-TYPE, 
ORGANISATION,  ORGANISATION-MATERIEL-ASSOCIATION} 

Notes  In  JSIMS,  an  equipment  group  represents  a  collection  of 

platforms. 

The  LC2IEDM  would  model  an  equipment  group  as  an 
ORGANISATION,  with  associated  MATERIEL.  Alternately,  it 
might  model  an  equipment  group  as  an  ORGANISATION  hold¬ 
ing  a  certain  quantity  of  MATERIEL-TYPE. 

6  items  map  to  ORGANIZATION  (236,  237,  238,  296,  150036, 
150102) . 

These  groups  are  the  materiel  part  of  Army  units  ranging 
from  a  single  platform  to  a  battalion.  In  order  to  capture 
the  Army  service  affiliation  of  an  equipment  group  it  would 
either  have  to  he  identified  with  a  Unit  in  the  LC2IEDM  or 
associated  with  a  Unit  through  an  OGANISATION- 
ORGANISATION-ASSOCIATION  . 

An  org.land.equip_group  object  is  clearly  distinguishable  from 
simple  org  in  the  LC2IEDM  via  the  UNIT-TYPE-SERVICE-CODE 
(-‘A’’  for  Army  for  ORG. LAND)  .  But,  An  org. land. .equip_group 
cannot  be  clearly  distinguished  from  an  org. land  object  or 
from  an  org. land. supply_cache  object  by  LC2IEDM  data  if  an 
equipment  group  is  not  modeled  as  a  u 

LC2IEDM  Notes:  MATERIEL  is  the  object  of  ORGANISATION-MATERIEL-ASSICATION; 

ORGANISATION  is  the  subject  of  ORGANISATION-MATERIEL- 
ASSOCIATION. 

MATERIEL-TYPE  is  a  subtype  of  OBJECT-TYPE; 

OBJECT-TYPE  is  used  as  a  classification  for  OBJECT-ITEM- 
TYPE; 

OBJECT-ITEM  is  classified  as  OBJECT-ITEM-TYPE; 

OBJECT-ITEM  is  a  supertype  of  ORGANISATION. 

OBJECT-ITEM  is  a  supertype  of  ORGANISATION. 

OBJECT-TYPE  is  used  as  a  classification  for  OBJECT-ITEM- 
TYPE; 

OBJECT-ITEM  is  classified  as  OBJECT-ITEM-TYPE; 

OBJECT-ITEM  is  a  supertype  of  ORGANISATION. 

ORGANISATION  is  the  subject  of  ORGANISATION-MATERIEL- 
ASSOCIATION. 

Computed  Degree  of  Alignment:  53 _ 
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org.land.supply_cache^{EQUIPMENT-TYPE,  MATERIEL,  ORGANISATION} 

Notes  A  JSIMS  supply  cache  is  a  type  of  organization.  It  would 

be  modeled  in  LC2IEDM  as  an  ORGANISATION  . 

6  items  map  to  ORGANIZATION  (236,  237,  238,  296,  150036, 
150102)  ., 

An  org.land.SLipply_cache  can  be  distinguished  from  other 
Army  organizations  which  are  units  because  it  is  not,  al¬ 
though  it  should  be  associated  with  an  Army  UNIT 
ORGANISATION  in  the  LC2IEDM.  It  is  distinguished  from  a 
simple  org  by  this  association.  An  org.land.supply_cache  cannot 
be  clearly  distinguished  from  an  org. land  object  or  from  an 
org. land. equip  group  object  by  LC2IEDM  data  if  an  equipment 
group  is  not  modeled  as  a  unit.  Hence  the  adjustment  fac¬ 
tor  of  (50  +  50/3  =  67)  The  LC2IEDM  OBJECT-TYPE-NAME  can 
be  used  to  support  this  distinction,  although  there  are  no 
standard  LC2IEDM  names  for  such  WARSIM  classes  . 
LC2IEDM  Notes:  EQUIPMENT-TYPE  is  a  subtype  of  MATERIEL-TYPE; 

MATERIEL-TYPE  is  a  subtype  of  OBJECT-TYPE; 

OBJECT-TYPE  is  used  as  a  classification  for  OBJECT-ITEM- 
TYPE; 

OBJECT-ITEM  is  classified  as  OBJECT-ITEM-TYPE; 

OBJECT-ITEM  is  a  supertype  of  ORGANISATION. 

MATERIEL  is  the  object  of  ORGANISATION-MATERIEL-ASSICATION; 
ORGANISATION  is  the  subject  of  ORGANISATION-MATERIEL- 
ASSOCIATION. 

Computed  Degree  of  Alignment:  52 _ 

C.2  LC2IEDM ^WARSIM  Alignment 

Table  C-2.  Materiel  Alignment  Summaries:  LC2IEDM ^WARSIM  Alignment 

CAPABILITY^}} 

Notes  The  CAPABILITY  entity  describes  general  characteristics  of 

capabilities. 

Some  attributes  probably  won't  align.  CAPABILITY  has  a  at¬ 
tribute  for  specifying  units  of  measure;  JSIMS  attributes' 
units  are  fixed.  CAPABILITY  can  distinguish  between  day¬ 
time  and  nighttime;  I  don't  think  JSIMS  can. 

CAPABILITY  itself  aligns  to  nothing.  However,  it's  the  parent 
of  several  classes.  Those  classes  will  probably  align  better. 
LC2IEDM  Notes:  From  the  Equipment  view. 

Computed  Degree  of  Alignment:  23 _ 
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EQLIIPMENT-TYPE^{abstract,abstract.land.equipment_type} 

Notes 

There  is  some  similarity  between  EQUIPMENT-TYPE  and 
abstract.land.equipment_type:  Both  model  cargo  dimensions,  for 
example. 

The  abstract  class  (superclass  of  abstract.land.equipment_type, 
conveniently)  models  an  ID. 

I'm  not  immediately  sure  how  to  model  EQUIPMENT-TYPE- 
FIRE-GUIDANCE-INDICATOR-CODE,  EQUIPMENT-TYPE-MOBILITY- 
CODE. 

Not  clear  if  there's  a  JSIMS  way  to  model  the  is-main- 
equipment-of  association  to  UNIT-TYPE.  The  org.land  class  has 
a  unit  kind  attribute,  but  using  that  would  be  modeling  the 
inverse  of  the  association. 

LC2IEDM  Notes: 

From  the  Equipment  view. 

Computed  Degree  of  Alignment: 

55 

FIRE-CAPABILITY^{abstract.  land, equipment, platform} 

Notes 

To  model  fire  capability,  JSIMS  must  be  able  to  record  a) 
that  equipment  can  fire  a  projectile,  and  b)  what  type  pro¬ 
jectile  the  equipment  fires. 

This  information  can  probably  be  modeled  through  the 
MIDB  that's  associated  with  platforms  and  equipment. 

LC2IEDM  Notes: 

From  the  Equipment  view. 

Computed  Degree  of  Alignment: 

20 

LAND-MANOEUVRE-CAPABILITY^{equipment,platform} 

Notes 

I  haven't  found  anything  in  JSIMS  that  correlates  platform 
mobility  to  terrain  types.  Possibly  the  MIDB  associated 
with  platforms  and  equipment  will  provide  that  informa¬ 
tion. 

LC2IEDM  Notes: 

From  the  Equipment  view. 

Computed  Degree  of  Alignment: 

22 

MATERIEL^{equipment, platform} 

Notes  The  platform  class  aligns  to  MATERIEL,  in  that  a  platform  repre¬ 

sents  an  object  with  physical  properties.  Platform  has  lots  of 
suhtypes.  Mayhe  most  of  them  align.  Does  the  LC2IEDM 
consider  things  like  a  surface  ship  (sLirface_ship  is  a  subclass) 
as  MATERIEL? 

The  equipment  class  would  also  align  to  MATERIEL. 

LC2IEDM  Notes:  From  the  Equipment  view. 

Computed  Degree  of  Alignment:  57 _ 
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MATERIEL- STATUS^{equipment.airbome_sensor.esm,  equipment.airbome_sensor.iff, 
equipment.airborne_sensor.ir,  equipment.airborne_sensor.optical,  equipment.equipment_radiating.airborne_radar, 
equipment.equipment_radiating.ald,  equipment.equipment_radiating.gps, 

equipment.equipment_radiating.rf_noiseJammer,  equipment.naval_sensor,  equipment.naval_weapon_system, 
equipment.sensor.comint,  equipment.sensor.elint,  equipment.sensor.radint,  equipment.sensor.sensor_deck, platform} 
Notes  JSIMS  has  many  classes  with  attributes  that  can  repre¬ 

sent  materiel  status.  However,  they  are  spread  throughout 
the  class  hierarchy,  rather  than  centralized  in  super¬ 
classes. 

It's  difficult  to  assign  a  degree  of  alignment  right  now;  that 
will  have  to  wait  until  lower  levels  of  analysis.  An  impor¬ 
tant  problem  will  be  determining  whether  JSIMS  can 
model  status  of  as  wide  a  range  of  materiel  as  the 
LC2IEDM  can. 

LC2IEDM  Notes:  From  the  Equipment  view. 

Computed  Degree  of  Alignment:  17 _ 

MATERIEL-TYPE^labstract} 

Notes 


LC2IEDM  Notes: 

Computed  Degree  of  Alignment _ 

OBJECT-ITEM^{equipment,  platform} 

Notes  The  equipment  class  can  model  the  name  and  ID  of  an 

OBJECT-ITEM. 

The  CATEGORY-CODE  attribute  would  be  fixed. 

LC2IEDM  Notes:  From  the  Equipment  view. 

Computed  Degree  of  Alignment:  100 _ 

OBJECT-ITEM-STATUS^{equipment,  platform} 

Notes  The  important  attribute  in  OBJECT-ITEM-STATUS  is  the  hos¬ 

tility  code.  The  JSIMS  classes  listed  have  a  faction  ID  at¬ 
tribute.  At  least  in  the  case  of  “platform”,  the  faction  ID  is 
one  of  a  fixed  set  of  values  that  don't  entirely  map  to  the 
hostility  codes  in  the  LC2IEDM. 

LC2IEDM  Notes:  From  the  Equipment  view. 

Computed  Degree  of  Alignment:  20 _ 

OBJECT-ITEM-TYPE^{} 

Notes  OBJECT-ITEM-TYPE  expresses  the  concept  of  an  M:N  relation¬ 

ship  between  OBJECT-ITEM  and  OBJECT-TYPE.  It's  not  clear 
that  JSIMS  can  model  an  M:N  relationship.  Our  assump¬ 
tion  is  that  class  “abstracf  and  its  subclasses  model  OBJECT- 
TYPE.  Although  one  instance  of  “abstract’  can  be  shared  by 
many  instances  of  “equipment”,  one  instance  of  “equipment”  can 
only  have  one  instance  of  “abstract”. 

LC2IEDM  Notes:  From  the  Equipment  view. 

Computed  Degree  of  Alignment:  38 _ 


The  MATERIEL-TYPE  entity  appears  to  align  in  principle  to 
the  abstract  class.  That  class'  parent  has  an  MIDB- 
designating  attribute.  Through  the  MIDB,  I  believe  many 
of  the  attributes  of  MATERIEL-TYPE  can  be  modeled. 

From  the  Equipment  view. 

:  69 
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OBJECT-TYPE^Iabstract} 

Notes 


The  OBJECT-TYPE  entity  appears  to  align  in  principle  to  the 
“abstract”  class.  That  class  has  an  MIDB-designating  attrib¬ 
ute.  Through  the  MIDB,  I  believe  many  of  the  attributes  of 
OBJECT-TYPE  can  be  modeled.  The  nationality-code  attribute  is 
questionable,  however. 

LC2IEDM  Notes:  From  the  Equipment  view. 

Computed  Degree  of  Alignment:  50 _ 

OBJECT-TYPE-CAPABILITY-NORM^{abstract.land.equipment_type} 

Notes  Given  the  breadth  of  capabilities  that  have  to  be  modeled, 

there  probably  isn't  a  good  way  to  align  this  entity  to 
JSIMS.  A  lot  of  separate  cases  will  need  to  be  considered 
(one  for  each  subtype  of  CAPABILITY). 

At  least  one  type  of  capability  can  be  modeled,  namely 
storage  capability.  The  class  abstract.land.equipmentjype  has 
the  necessary  attributes. 

LC2IEDM  Notes:  From  the  Equipment  view. 

Computed  Degree  of  Alignment:  75 _ 

STCRAGE-CAPABILITY^{abstract.land.equipment_type} 

Notes  STCRAGE-CAPABILITY  just  records  the  capability  to  store.  The 

actual  amount  is  held  in  CBJECT-TYPE-CAPABILITY-NCRM. 
Therefore,  the  alignment  of  STCRAGE-CAPABILITY  won't  in¬ 
volve  aligning  to  attributes  of  abstract.land.equipmentjype,  just 
structural  alignment. 

LC2IEDM  Notes:  From  the  Equipment  view. 

Computed  Degree  of  Alignment:  20 _ 

SLIRVEILLANCE-CAPABILITY^{equipment.airborne_sensor,  equipment.airborne_sensor.esm, 
equipment.airborne_sensor.iff,  equipment.airborne_sensor.ir,  equipment.airborne_sensor.optical,  equipment.sensor, 
equipment.sensor.comint,  equipment.sensor.elint,  equipment.sensor.opint,  equipment.sensor.radint, 
equipment.sensor.sensor_deck} 

Notes  The  SURVEILLANCE-CAPABILITY  probably  will  be  modeled 

structurally  rather  than  through  attributes  of  the  listed 
JSIMS  classes. 

LC2IEDM  Notes:  From  the  Equipment  view. 

Computed  Degree  of  Alignment:  24 _ 
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Appendix  D.  Environment  Alignment  Results 


This  appendix  summarizes  the  assessment  of  the  alignment  between  the  TCDM  and  the 
LC2IEDM.  Only  Coneeptual-  and  Entity-level  assessments  are  shown;  the  underlying 
State-  and  Value-level  assessments  are  omitted  in  the  interests  of  brevity.  The  reader  in¬ 
terested  in  the  State-  and  Value-level  assessments  ean  find  them  in  the  alignment  assess¬ 
ment  database. 

Eaeh  assessment  follows  a  standard  format.  It  presents  a  eombination  of  the  following 
items: 

•  The  assessment  “signature”,  whieh  is  of  the  form  a  ^  {ei ,  £2 ,  •  •  • ,  }  •  Its  interpre¬ 
tation  is  that  element  a  in  one  model  aligns  to  elements  in  the  other 

model.  If  the  set  {gj ,  gj ,  •  •  • ,  }  is  empty,  then  a  does  not  align. 

•  Notes,  whieh  show  comments  the  assessor  made.  Notes  can  be  general  (labeled 
just  “Notes”),  or  specific  to  TCDM  or  the  EC2IEDM. 

•  The  Computed  Degree  of  Alignment,  which  is  the  rolled-up  value  calculated  to  be 
the  degree  to  which  element  a  aligns. 

•  An  indication  if  the  assessment  is  terminal  or  not  applicable  to  alignment. 

Not  all  of  these  items  need  be  present  for  a  given  assessment.  An  entry  is  shown  only  if 
the  assessor  provided  information  on  it. 

D.l  TCDM-to-LC2IEDM  Level  Alignment 

This  section  presents  the  results  of  determining  the  degree  to  which  the  TCDM  aligns  to 
the  EC2IEDM.  The  following  entries  were  made  for  Conceptual-level  alignment: 


Conceptual-Level  Alignment  of  Terrain 

Notes: 

Roughly  speaking,  the  JSIMS  concept  of  terrain,  as  ex¬ 
pressed  through  the  TCDM,  is  modeled  hy  the  LC2IEDM 
notion  of  geographic  features. 

The  Geographic  Feature  view  comprises  terrain  character¬ 
istics,  The  TCDM  includes  man-made  entities  (e.g., 
amusement  parks).  Terrain  therefore  aligns  to  the  Facility 
view  as  well. 

Computed  Degree  of  Alignment: 

41 

The  following  table  gives  the  assessment  of  each  Entity-level  element  (TCDM  feature) 
that  was  assessed  as  part  of  Conceptual-level  alignment. 

Table  D-1.  TCDM  Feature  Assessment  Summaries 


Administrative  Area^{CONTROL-FEATURE} 

LC2IEDM  Notes:  no  category  code  exists 

Computed  Degree  of  Alignment:  42 _ 
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Administrative  Boundary^{CONTROL-FEATURE-TYPE} 

Notes  To  load  all  data  pertaining  to  this  class  may  require  using 

both  CONTROL-FEATURE-TYPE  and  CONTROL-FEATURE,  since 
the  LOCATION -related  portion  can  only  be  accessed  using 
FEATURE-LOCATION.  In  addition,  the  LINE,  SURFACE  and 
SURFACE-REGION  tables  also  may  be  required. 

7  items  map  to  BDYPOA  (60001,  60010,  60026,  60042,  60060, 
60061,  60073). 

LC2IEDM  Notes:  mapped  to  "Boundary,  political/administrative".  ECO:  BDYPOA 

1000075 

Computed  Degree  of  Alignment:  23 _ 

Aerial  Cableway  Lines  /  Ski  Lift  Lines^{CONTROL-FEATURE-TYPE} 

Notes  This  Environmental  Class  may  also  be  viewed  as 

EQUIPMENT-TYPE.  The  current  assessment  assumes  that  the 
user  is  not  interested  in  the  operation  of  the  conveyor  sys¬ 
tem,  but  only  wants  to  track  it  on  a  display,  overlay,  or 
map. 

LC2IEDM  Notes:  no  ECC  exists. 

Computed  Degree  of  Alignment:  76 _ 

Airport /Airfield^{FACILITY-TYPE,  GEOGRAPHIC-FEATURE-TYPE} 

Notes  There  exists  a  FACILITY-TYPE-CATEGORY-CODE  for  airport  in 

LC2IEDM. 

4  items  map  to  AIR  (60003,  60004,  60129,  60146). 

LC2IEDM  Notes:  Maps  to  AIR,  Airfield/airport/airstrip  1000037. 

Computed  Degree  of  Alignment:  33 _ 

Airport  Lighting^{EQUIPMENT-TYPE} 

Notes  The  current  assessment  is  based  on  the  definition  which 

appears  to  focus  on  the  equipment  nature  of  the  class.  Air¬ 
port  equipment  is  also  included  in  the  definition  for 
FACILITY-TYPE  =  Airport,  so  could  be  considered  a  subset  of 
airport/air  strip.  If  the  user  only  wants  to  depict  this  class 
in  a  display,  overlay  or  map,  then  it  could  be  handled  as  a 
CONTROL-FEATURE-TYPE. 

4  items  map  to  AIR  (60003,  60004,  60129,  60146). 

LC2IEDM  Notes:  mapped  to  "Beacon".  ECC  BEACON  1000178 

Computed  Degree  of  Alignment:  35 _ 

Amusement  Park-^{FACILITY-TYPE,  GEOGRAPHIC-FEATURE-STATUS} 

Notes  No  ECC  exists.  Can  use  FACILITY-TYPE  =  "NOS".  The  current 

assessment  is  based  on  the  definition  which  appears  to  fo¬ 
cus  on  the  facility  nature  of  the  class.  If  the  user  only 
wants  to  depict  this  class  in  a  display,  overlay  or  map,  then 
it  should  be  handled  as  a  CONTROL-FEATURE-TYPE. 

22  items  map  to  FACILITY-TYPE  =  NOS  (60005,  60006,  60007, 
60047,  60051,  60054,  60055,  60056,  60062,  60066,  60070, 
60083,  60084, 60089, 60094, 60098, 60099,  60108,  60109, 
60136,  60141,  60147). 

LC2IEDM  Notes:  No  ECC  exists. 

Computed  Degree  of  Alignment:  29 _ 

Anchorage^{FACILITY-TYPE} 
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Notes 


No  ECC  exists.  The  purpose  for  this  line  is  usually  not  re¬ 
lated  to  military  operations,  hut  is  used  for  charting,  map¬ 
ping,  hydrographic  surveys.  Thus,  it  would  not  likely  he  a 
CONTROL-FEATURE.  On  an  overlay,  it  can  simply  he  repre¬ 
sented  as  a  LOCATION.  It  can  he  associated  with  the  Aque¬ 
duct  Facility  thru  FACILITY-LOCATION. 

LC2IEDM  Notes:  mapped  to  Bearing  Line,  ECC  BEARING  LINE  1000109. 

Computed  Degree  of  Alignment:  26 _ 

Armistice  Line^{CONTROL-FEATURE-TYPE} 

Notes  To  load  all  data  pertaining  to  this  Environment  Class  may 

require  using  hoth  CONTROL-FEATURE-TYPE  and  CONTROL- 
FEATURE,  since  the  LOCATION-related  portion  can  only  he 
accessed  using  FEATURE-LOCATION.  In  addition,  the  LINE, 
SURFACE  and  SURFACE-REGION  tables  also  may  he  required. 

7  items  map  to  BDYPOA  (60001,  60010,  60026,  60042,  60060, 
60061,  60073). 

LC2IEDM  Notes:  mapped  to  Boundary,  political/administrative,  ECC  BDYPOA 

1000074. 

Computed  Degree  of  Alignment:  28 _ 

Assembly  Plant^{FACILITY-TYPE} 

Notes  The  current  assessment  is  based  on  the  definition  which 

appears  to  focus  on  the  facility  nature  of  the  class.  If  the 
user  only  wants  to  depict  this  class  in  a  display,  overlay  or 
map,  then  it  should  be  handled  as  a  CONTROL-FEATURE-TYPE. 
To  load  all  data  pertaining  to  this  Environment  Class  may 
require  using  both  FACILITY-TYPE  and  FACILITY,  since  the 
LOCATION-related  portion  can  only  be  accessed  using 
FACILITY-LOCATION.  In  addition,  the  LINE,  SURFACE  and 
SURFACE-REGION  tables  also  may  be  required. 

7  items  map  to  INDINS  (60011,  60013,  60026,  60106,  60107, 
60120,  60130). 

LC2IEDM  Notes:  mapped  to  Industrial  Installation,  ECC  INDINS  1000110. 

Computed  Degree  of  Alignment:  35 _ 

Bamboo  /  Cane^{GEOGRAPHIC-FEATURE-TYPE} 

Notes  No  ECC  exists.  Closest  mapping  is  to  “Tree”  ECC  TRE. 

15  items  map  to  GEOGRAPHIC-FEATURE-TYPE  =  NOS  (60012, 
60015,  60052,  60076,  60096,  60100, 60115,  60116, 60131, 
60136,  60137,  60140,  60144,  60146,  60153,  60160). 

TCDM  Notes:  A  site  of  woody  and/or  tree-like  grasses  of  the  tropical  or 

temperate  regions  that  have  jointed  hollow  stems  with 
solid  nodes. 

LC2IEDM  Notes:  No  ECC  exists.  Most  closely  maps  to  “Tree”  ECC  TRE,  woody 

perennial  plants  having  a  self-supporting  stem  or  trunk. 
Can  also  use  “NOS”  and  use  OBJECT-ITEM-NAME  to  specify 
“bamboo/cane”. 

Computed  Degree  of  Alignment:  12 _ 
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Breakwater  /  Groin^{FACILITY-TYPE} 
Notes 

no  FACILITY-TYPE-CATEGORY-CODE  exists  for  this  in 

LC2IEDM.  Possibly  maps  to  DamAA/ier  which  does  have  a 
FACILITY-TYPE-CATEGORY-CODE. 

3  items  map  to  DAM  (60016,  60041,  60075). 

LC2IEDM  Notes: 

mapped  to  “Dam/Weir”  ECC  DAM  1000117 

Computed  Degree  of  Alignment: 

31 

Bridge  /  Overpass  /  Viaduct^{FACILITY-TYPE} 

Notes 

There  exists  a  FACILITY-TYPE-CATEGORY-CODE  for 
bridge/OverpassA/iaduct  in  LC2IEDM.  This  is  the  primary  map¬ 
ping. 

4  items  map  to  BRG  (60019,  60020,  60027,  60049). 

LC2IEDM  Notes: 

Maps  to  BRG,  Bridge/overpass/viaduct  1000039. 

Computed  Degree  of  Alignment: 

44 

Bridge  Span^{FACILITY-TYPE} 

Notes 

4  items  map  to  BRG  (60019,  60020,  60027,  60049). 

LC2IEDM  Notes: 

maps  to  “Bridge/overpass/viaduct”  ECC  BRG  1000039. 

Computed  Degree  of  Alignment: 

51 

Building^{FACILITY-TYPE} 
LC2IEDM  Notes: 

maps  to  “Building”  ECC  BLD  1000038 

Computed  Degree  of  Alignment: 

55 

Built  UpArea^{FACILITY-TYPE} 

Notes 

There  is  a  FACILITY-TYPE-CATEGCRY-CCDE  for  Built  Up  Area  in 
LC2IEDM. 

LC2IEDM  Notes: 

Maps  to  BUA,  Built-up  area  1000111. 

Computed  Degree  of  Alignment: 

59 

Canal^{FACILITY-TYPE,  GEOGRAPHIC-FEATURE-STATUS} 

LC2IEDM  Notes: 

maps  to  “Canal”  ECC  CAN  1000112 

Computed  Degree  of  Alignment: 

30 

Canal  Centerline  /  Nexus^{CONTROL-FEATURE,  GEOGRAPHIC-FEATURE-STATUS} 

Notes 

Can  be  associated  with  Canal  through  FACILITY-LCCATICN. 

LC2IEDM  Notes: 

maps  to  “Bearing  line”  ECC  BERLIN  1000109. 

Computed  Degree  of  Alignment: 

26 

Cart  Track^{FACILITY-TYPE,  GEOGRAPHIC-FEATURE-STATUS} 

Notes 

2  items  map  to  RD  (60025,  60123). 

LC2IEDM  Notes: 

maps  to  “Road”  ECC  RD  1000058 

Computed  Degree  of  Alignment: 

20 

Catalytic  Cracker^{EQU  1  PM  ENT-TYPE} 
Notes 

7  items  map  to  INDINS  (60011,  60013,  60026,  60106,  60107, 
60120,  60130). 

LC2IEDM  Notes: 

no  ECC  exists. 

Computed  Degree  of  Alignment: 

48 
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Causeway^{FACI  LITY-TYPE} 

Notes 

4  items  map  to  BRG  (60019,  60020,  60027,  60049). 

LC2IEDM  Notes: 

maps  to  “Bridge/overpass/viaduct”  ECC  BRG  1000039 

Computed  Degree  of  Alignment: 

42 

Cease  Fire  Line^{CONTROL-FEATURE-TYPE} 

Notes 

7  items  map  to  BDYPOA  (60001,  60010,  60026,  60042,  60060, 
60061,  60073). 

LC2IEDM  Notes: 

maps  to  “Boundary,  political/administrative”  ECC  BDYPOA  1000074 

Computed  Degree  of  Alignment: 

28 

Chimney  /  Smokestack^{FACI  LITY-TYPE} 

LC2IEDM  Notes: 

maps  to  “Chimney/smokestack”  ECC  CHM  1000113. 

Computed  Degree  of  Alignment: 

85 

Cistern^lFACI  LITY-TYPE} 

Notes 

No  ECC  exists.  May  use  “Water  Tower”  or  “Reservoir”,  de¬ 
pending  on  elevation  of  the  cistern  with  respect  to  the 
ground. 

2  items  map  to  FACILITY-CODE  =  NOS,  STORAGE-CAPABILITY  = 
WAT  (60030,  60164). 

TCDM  Notes: 

A  man-made  container  used  for  collection  or  storage  of  rain 
water. 

LC2IEDM  Notes: 

No  ECC  exists.  May  map  to  “Water  Tower”  ECC  WTW 
1000070.  May  more  closely  map  to  “Reservoir”  ECC  RES  if 
not  elevated.  Cisterns  may  he  underground,  on  the  ground, 
or  he  open  reservoirs. 

Computed  Degree  of  Alignment: 

35 

Claim  Line^{CONTROL-FEATURE-TYPE} 

Notes 

2  items  map  to  BDYOR  (60016,  60031). 

LC2IEDM  Notes: 

maps  to  “Boundary,  organization”  ECC  BDYOR  1000073 

Computed  Degree  of  Alignment: 

38 

Cleared  Way  /  Cut  Line  /  Firebreak^{FACILITY-TYPE,  GEOGRAPHIC-FEATURE-STATUS} 

LC2IEDM  Notes: 

maps  to  “Cleared  way/firehreak”  ECC  CWY  1000114. 

Computed  Degree  of  Alignment: 

25 

Coastline  /  Shoreline^{GEOGRAPHIC-FEATURE-TYPE} 

Notes 

2  items  map  to  BCH  (60033,  60056). 

LC2IEDM  Notes: 

mapped  to  “Beach”  ECC  BCH  1000002. 

(admittedly  a  poor  map) 

Computed  Degree  of  Alignment: 

25 

Communication  Building^{FACI LITY-TYPE} 

LC2IEDM  Notes: 

mapped  to  “Communications  Building”  ECC  COB  1000042. 

Computed  Degree  of  Alignment: 

69 

Communication  Tower^{FACI  LITY-TYPE} 

Notes 

2  items  map  to  COT  (60035,  60079). 

LC2IEDM  Notes: 

mapped  to  “Communications  Tower”  ECC  COT  1000043. 

Computed  Degree  of  Alignment: 

64 
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Disk  /  Dish  Antenna^{EQUIPMENT-TYPE} 

LC2IEDM  Notes:  mapped  to  “Communications  antenna”  ECC  COMANT  1000171  or 

to  “Early  Warning/acquisition  radar”  ECC  EWARAD  1000181  or  to 

air  traffic  control  radar  or  to  fire  control  radar . 

Computed  Degree  of  Alignment:  85 _ 

Drydock^{FACILITY-TYPE} 

Notes  No  ECC  exists  for  drydock.  The  closest  concept  is  Maintenance 

Facility,  ECC  MAINTF.  Ship  maintenance  facilities  are  usually 
located  at  major  ports,  and  often  include  a  drydock  for  hull 
repairs. 

22  items  map  to  FACILITY-TYPE  =  NOS  (60005,  60006,  60007, 
60047,  60051,  60054,  60055,  60056,  60062,  60066,  60070, 
60083,  60084,  60089,  60094,  60098,  60099,  60108,  60109, 
60136,  60141,  60147). 

TCDM  Notes:  A  structure  providing  support  for  a  vessel,  which  has  a 

means  of  removing  water  so  that  the  bottom  of  the  vessel 
can  he  exposed. 

LC2IEDM  Notes:  no  ECC  exists  for  drydock.  Closest  mapping  is  to  MAINTF, 

maintenance  facility. 

Computed  Degree  of  Alignment:  35 _ 

Embankment  /  Fill^{GEOGRAPHIC-FEATURE-TYPE} 

LC2IEDM  Notes:  mapped  to  “Embankment/fill”  ECC  EMB  1000023 

Computed  Degree  of  Alignment:  50 _ 

Engineering  Bridge^{FACILITY-TYPE} 

Notes  4  items  map  to  BRG  (60019,  60020,  60027,  60049). 

LC2IEDM  Notes:  mapped  to  “Bridge/overpass/viaducf’  ECC  BRG  1000039 

Computed  Degree  of  Alignment:  42 _ 

Exposed  Bedrock^{G EGG RAPH IC-FEATU RE-TYPE} 

Notes  2  items  map  to  RST  (60050,  60125). 

LC2IEDM  Notes:  mapped  to  “Rock  strata/rock  formation”  ECC  RST  1000052. 

Computed  Degree  of  Alignment:  35 _ 

Extraction  Mine^{FACILITY-TYPE} 

Notes  22  items  map  to  FACILITY-TYPE  =  NOS  (60005,  60006,  60007, 

60047,  60051,  60054,  60055,  60056,  60062,  60066,  60070, 
60083,  60084,  60089,  60094,  60098, 60099,  60108,  60109, 
60136,  60141,  60147). 

LC2IEDM  Notes:  no  ECC  exists 

Computed  Degree  of  Alignment:  23 _ 

Fault^{G  EOGRAPH I C-FEATU  RE-TYPE} 

Notes  15  items  map  to  GEOGRAPHIC-FEATURE-TYPE  =  NOS  (60012, 

60015,  60052,  60076,  60096,  60100, 60115,  60116, 60131, 
60136,  60137,  60140,  60144,  60146,  60153,  60160). 
LC2IEDM  Notes:  no  ECC  exists. 

Computed  Degree  of  Alignment:  26 _ 
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Ferry  Crossing^{FACILITY-TYPE} 

Notes  mapped  to  “Crossing,  railway/river”  ECC  XRR 

TCDM  Notes:  A  route  in  a  body  of  water  where  a  ferry  crosses  from  one 

shoreline  to  another. 

LC2IEDM  Notes:  mapped  to  “Crossing,  railway/river”  ECC  XRR 

Computed  Degree  of  Alignment:  33 _ 

Filtration  Beds  /  Aeration  Beds^{FACILITY-TYPE,  GEOGRAPHIC-FEATURE-STATUS} 

Notes  22  items  map  to  FACILITY-TYPE  =  NOS  (60005,  60006,  60007, 

60047,  60051,  60054,  60055,  60056,  60062,  60066,  60070, 
60083,  60084,  60089,  60094,  60098,  60099,  60108,  60109, 
60136,  60141,  60147). 

LC2IEDM  Notes:  no  ECC  exists 

Computed  Degree  of  Alignment:  25 _ 

Fish  Hatchery  /  Fish  Farm  /  Marine  Farm^{FACILITY-TYPE,  GEOGRAPHIC-FEATURE-STATUS} 

Notes  22  items  map  to  FACILITY-TYPE  =  NOS  (60005,  60006,  60007, 

60047,  60051,  60054,  60055,  60056,  60062,  60066,  60070, 
60083,  60084,  60089,  60094,  60098,  60099,  60108,  60109, 
60136,  60141,  60147). 

LC2IEDM  Notes:  no  ECC  exists 

Computed  Degree  of  Alignment:  16 _ 

Flare  Pipe^{FACILITY-TYPE} 

Notes  22  items  map  to  FACILITY-TYPE  =  NOS  (60005,  60006,  60007, 

60047,  60051,  60054,  60055,  60056,  60062,  60066,  60070, 
60083,  60084,  60089,  60094,  60098,  60099,  60108,  60109, 
60136,  60141,  60147). 

LC2IEDM  Notes:  no  ECC  exists 

Computed  Degree  of  Alignment:  44 _ 

Ford^{GEOGRAPHIC-FEATURE-STATUS,  GEOGRAPHIC-FEATURE-TYPE} 

LC2IEDM  Notes:  mapped  to  “Ford”  ECC  FRD  1000026 

Computed  Degree  of  Alignment:  36 _ 

Foreshore^{GEOGRAPHIC-FEATURE-STATUS,  GEOGRAPHIC-FEATURE-TYPE} 

Notes  2  items  map  to  BCH  (60033,  60056). 

LC2IEDM  Notes:  mapped  to  “Beach”  ECC  BCH  1000002 

Computed  Degree  of  Alignment:  21 _ 

Geographic  Information  Area^{GEOGRAPHIC-FEATURE-TYPE} 

Notes  3  items  map  to  CONTROL-FEATURE-TYPE  =  NOS  (60044,  60059, 

60157). 

Assessment  is  N/A. _ 

Grain  Bin  /  Silo^{FACILITY-TYPE} 

Notes  Maps  to  FACILITY-TYPE  “Tower  (non-communications)”  ECC  TOW, 

enhanced  hy  STORAGE-CAPABILITY. 

2  items  map  to  TOW,  enhanced  hy  STORAGE-CAPABILITY 
(60060,  60061). 

LC2IEDM  Notes:  mapped  to  “Tower  (non-communications)”  ECC  TOW  1000124 

Computed  Degree  of  Alignment:  62 _ 
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Grain  Elevator^{FACILITY-TYPE} 

Notes  Maps  to  FACILITY- TYPE  “Tower  (non-communications)”  ECC 

TOW,  enhanced  by  STORAGE-CAPABILITY.  Does  not  include  the 
concepts  of  grain  processing,  loading,  or  unloading. 

2  items  map  to  TOW,  enhanced  by  STORAGE-CAPABILITY 
(60060,  60061). 

TCDM  Notes:  A  tall  structure,  equipped  for  loading,  unloading,  process¬ 

ing,  and  storing  grain. 

LC2IEDM  Notes:  mapped  to  “Tower  (non-communications)”  ECC  TOW  1000124 

Computed  Degree  of  Alignment:  60 _ 

Grandstand^{FACILITY-TYPE} 

Notes  22  items  map  to  FACILITY-TYPE  =  NOS  (60005,  60006,  60007, 

60047,  60051,  60054,  60055,  60056,  60062,  60066,  60070, 
60083,  60084,  60089,  60094,  60098,  60099,  60108,  60109, 
60136,  60141,  60147). 

LC2IEDM  Notes:  no  ECC  exists 

Computed  Degree  of  Alignment:  31 _ 

Grassland^{GEOGRAPHIC-FEATURE-STATUS,  GEOGRAPHIC-FEATURE-TYPE} 

LC2IEDM  Notes:  mapped  to  “Grassland”  ECC  GSL  1000030 

Computed  Degree  of  Alignment:  19 _ 

Ground  Surface  Element^{GEOGRAPHIC-FEATURE-STATUS,  GEOGRAPHIC-FEATURE-TYPE} 

Notes  Maps  to  GEOGRAPHIC-FEATURE-STATUS,  which  includes  9 

enumerated  values  for  GEOGRAPHIC-FEATURE-STATUS- 
SURFACE-CONDITION. 

TCDM  Notes:  The  surface  soil  characteristics  of  the  terrain. 

LC2IEDM  Notes:  no  ECC  exists 

Computed  Degree  of  Alignment:  25 _ 

Gully  /  Gorge^{GEOGRAPHIC-FEATURE-TYPE} 

LC2IEDM  Notes:  mapped  to  “Gully  (gorge)”  ECC  GUL  1000030 

Computed  Degree  of  Alignment:  44 _ 

Hardened  Aircraft  Shelter^{FACILITY-TYPE} 

LC2IEDM  Notes:  mapped  to  “Shelter,  surface”  ECC  SHLSUR  1000069 

Computed  Degree  of  Alignment:  76 _ 

Hedgerow-^{GEOGRAPHIC-FEATURE-TYPE} 

Notes  Mapped  to  FACILITY-TYPE  “Fence”,  a  man-made  barrier  of 

relatively  light  structure  used  an  enclosure  or  boundary. 
Could  alternatively  be  mapped  to  CONTROL-FEATURE-TYPE 
“Obstacle  Line”,  ECC  OBSLIN,  a  single  line  of  natural  or  man¬ 
made  obstacles. 

TCDM  Notes:  A  continuous  growth  of  shrubbery  planted  as  a  fence,  a 

boundary,  or  a  windbreak. 

LC2IEDM  Notes:  mapped  to  “Scrub/brush”  ECC  SCR  1000055 

Computed  Degree  of  Alignment:  67 _ 

Heliport^{FACILITY-TYPE} 

LC2IEDM  Notes:  mapped  to  “Heliport”  ECC  HPT  1000052 

Computed  Degree  of  Alignment:  52 _ 

Hops^{FACILITY-TYPE} 
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Notes  Although  no  FACILITY-TYPE-CATEGORY-CODE  exists  for  Hops  in 

LC2IEDM,  it  is  mapped  here  as  something  that  is  man¬ 
made  and  managed  or  controlled,  much  like  Cropland,  which 
does  have  a  FACILITY-TYPE-CATEGORY-CODE. 

3  items  map  to  CRP  (60039,  60069,  60119). 

LC2IEDM  Notes:  Maps  to  CRP,  Cropland. 

Computed  Degree  of  Alignment:  20 _ 

Hydrographic  Lock^{FACILITY-TYPE} 

Notes  22  items  map  to  FACILITY-TYPE  =  NOS  (60005,  60006,  60007, 

60047,  60051,  60054,  60055,  60056,  60062,  60066,  60070, 
60083,  60084,  60089,  60094,  60098, 60099,  60108,  60109, 
60136,  60141,  60147). 

LC2IEDM  Notes:  no  ECC  exists. 

Computed  Degree  of  Alignment:  43 _ 

Ice  Cliff^{GEOGRAPHIC-FEATURE-TYPE} 

Notes  2  items  map  to  CLF  (60014,  60071). 

LC2IEDM  Notes:  mapped  to  “Cliff/escarpmenf’  ECC  CLF  1000010. 

Computed  Degree  of  Alignment:  38 _ 

Infantry  Trench^{FACILITY-TYPE} 

Notes  There  exists  a  FACILITY-TYPE-CATEGORY-CODE  for  Trench  in 

LC2IEDM,  so  the  primary  mapping  is  to  FACILITY-TYPE. 

An  alternative  mapping  could  he  to  CONTROL-FEATURE: 

To  load  all  data  pertaining  to  this  Environment  Class  may 
require  using  hoth  CONTROL-FEATURE-TYPE  and  CONTROL- 
FEATURE,  since  the  LOCATION-related  portion  can  only  he 
accessed  using  FEATURE-LOCATION.  In  addition,  the  LINE, 
SURFACE  and  SURFACE-REGION  tables  also  may  he  required. 
LC2IEDM  Notes:  Maps  to  TCH,  Trench  100065. 

Computed  Degree  of  Alignment:  96 _ 

International  Date  Line^{CONTROL-FEATURE-TYPE} 

Notes  No  ECC  exists.  On  a  map  overlay,  may  he  shown  simply  as 

a  location  line  and  given  the  name  “International  Date 
Line”.  Might  also  he  used  as  an  administrative  CONTROL- 
FEATURE  for  purposes  of  time-keeping. 

LOCATION  is  linked  to  CONTROL-FEATURE  thru  FEATURE- 
LOCATION  and  FEATURE. 

7  items  map  to  BDYPOA  (60001,  60010,  60026,  60042,  60060, 
60061,  60073). 

LC2IEDM  Notes:  Maps  to  “Boundary,  political/administrative”  ECC  BDYPOA 

Computed  Degree  of  Alignment:  28 _ 

Irrigation  Ditch^{FACILITY-TYPE} 

Notes  Exactly  the  same  definitions  in  hoth  TCDM  and  LC2IEDM: 

“A  channel  constructed  for  the  purpose  of  irrigation  or 
drainage”. 

LC2IEDM  Notes:  mapped  to  “Ditch”  ECC  DCH  1000118. 

Computed  Degree  of  Alignment:  75 _ 
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Jetty^{FACILITY-TYPE} 

Notes  3  items  map  to  DAM  (60016,  60041,  60075). 

LC2IEDM  Notes:  mapped  to  “Dam/Weir”  ECC  DAM  1000117 

Computed  Degree  of  Alignment:  31 _ 

Lagoon  /  Reef  Pool^{GEOGRAPHIC-FEATURE-STATUS,  GEOGRAPHIC-FEATURE-TYPE} 

Notes  15  items  map  to  GEOGRAPHIC-FEATURE-TYPE  =  NOS  (60012, 

60015, 60052, 60076,  60096,  60100,  60115,  60116,  60131, 
60136,  60137,  60140,  60144,  60146,  60153,  60160). 
LC2IEDM  Notes:  no  ECC  exists 

Computed  Degree  of  Alignment:  13 _ 

Lake  /  Pond^{GEOGRAPHIC-FEATURE-STATUS,  GEOGRAPHIC-FEATURE-TYPE} 

LC2IEDM  Notes:  mapped  to  “Lake/Pond”  ECC  LAK  1000039 

Computed  Degree  of  Alignment:  37 _ 

Lake  /  Pond  Centerline  /  Nexus^{GEOGRAPHIC-FEATURE-STATUS,  GEOGRAPHIC-FEATURE-TYPE} 

Notes  Associate  the  LOCATION  Line  with  the  Lake  thru  FEATURE- 

LOCATION,  FEATURE,  and  GEOGRAPHIC-FEATURE,  which  links 
hack  to  GEOGRAPHIC-FEATURE-TYPE. 

LC2IEDM  Notes:  mapped  to  “Bearing  Line”  ECC  BERLIN  1000109 

Computed  Degree  of  Alignment:  34 _ 

Lighthouse^{FACILITY-TYPE} 

Notes  2  items  map  to  COT  (60035,  60079). 

LC2IEDM  Notes:  mapped  to  “Communications  Tower”  ECC  COT  1000043 

(not  a  great  mapping) 

Computed  Degree  of  Alignment:  64 _ 

Mandate  Line  /  Convention  Line^{CONTROL-FEATURE-TYPE} 

Notes  7  items  map  to  BDYPOA  (60001,  60010,  60026,  60042,  60060, 

60061,  60073). 

LC2IEDM  Notes:  mapped  to  “Boundary,  political/administrative”  ECC  BDYPOA 

1000074 

Computed  Degree  of  Alignment:  28 _ 

Maritime  Limit  Boundary^{CONTROL-FEATURE-TYPE} 

Notes  Maps  primarily  to  LOCATION-CATEGORY-CODE  =  LN  (Line),  a 

one -dimensional  location  that  is  defined  hy  2  or  more 
points  connected  hy  straight  line  segments  in  an  ordered 
sequence.  If  the  first  and  last  point  are  the  same,  it  creates 
a  boundary. 

Loosely  maps  to  ECC  RELL,  “Release  Line”,  A  Phase  Line  used 
in  river-crossing  operations  that  delineates  a  change  in 
headquarters  controlling  movement. 

7  items  map  to  BDYPOA  (60001,  60010,  60026,  60042,  60060, 
60061,  60073). 

TCDM  Notes:  A  line  where  on  either  side  certain  activities  or  factors  of 

significance  to  navigation  and/or  operation  apply. 

LC2IEDM  Notes:  No  ECC  exists,  partially  maps  to  “Release  Line”  ECC  RELL 

Computed  Degree  of  Alignment:  28 _ 
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Maritime  Mole^{FACILITY-TYPE} 

Notes  2  items  map  to  TRANSF  (60062,  60092). 

LC2IEDM  Notes:  mapped  to  “Transloading  Facility”  ECC  TRANSF  1000026 

Computed  Degree  of  Alignment:  34 _ 

Maritime  Platform^{FACILITY-TYPE} 

Notes  22  items  map  to  FACILITY-TYPE  =  NOS  (60005,  60006,  60007, 

60047,  60051,  60054,  60055,  60056,  60062,  60066,  60070, 
60083,  60084,  60089,  60094,  60098, 60099,  60108,  60109, 
60136,  60141,  60147). 

LC2IEDM  Notes:  no  ECC  exists 

Computed  Degree  of  Alignment:  44 _ 

Maritime  Wreck^{CONTROL-FEATURE-TYPE} 

Notes  No  ECC  exists.  Might  be  mapped  to  FACILITY-TYPE  =  DMDBRS 

(demolition  debris)  —  the  debris  left  over  from  the  demoli¬ 
tion  of  an  object.  Alternatively,  one  could  use  FACILITY-TYPE 
-  RUI  (Ruins)  —  a  site  or  location  where  remains  of  ancient 
civilization  or  human  activity  have  been  discovered.  It 
could  possibly  be  a  CONTROL-FEATURE,  if  there  were  any 
military,  political,  or  administrative  significance,  or  if  the 
area  of  the  wreck  posed  a  hazard  to  navigation,  etc. 

22  items  map  to  FACILITY-TYPE  =  NOS  (60005,  60006,  60007, 
60047,  60051,  60054,  60055,  60056,  60062,  60066,  60070, 
60083,  60084,  60089,  60094,  60098,  60099,  60108,  60109, 
60136,  60141,  60147). 

TCDM  Notes:  The  ruined  remains  of  a  vessel. 

LC2IEDM  Notes:  mapped  to  “Point  of  Interest’  ECC  PTINT  or  to  “No-Go  Area”  ECC 

NGA. 

Computed  Degree  of  Alignment:  28 _ 

Marsh  /  Swamp^{GEOGRAPHIC-FEATURE-TYPE} 

LC2IEDM  Notes:  mapped  to  “Marsh/swamp”  ECC  MSH  1000041. 

Computed  Degree  of  Alignment:  32 _ 

Military  Area^{CONTROL-FEATURE-TYPE} 

LC2IEDM  Notes:  mapped  to  “Named  area  of  interest”  ECC  NAMAIN  1000063 

Computed  Degree  of  Alignment:  70 _ 

Minefield^{FACILITY-TYPE} 

LC2IEDM  Notes:  mapped  to  “Minefield,  not  otherwise  specified”  ECC  MINEFD 

1000078. 

Computed  Degree  of  Alignment:  57 _ 
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Miscellaneous  Obstacle^{CONTROL-FEATURE-TYPE} 

Notes 

No  ECC  exists.  Could  use  “Tetrahedron”  to  represent  the  area 
or  volume,  which  can  he  further  described  using  LOCATION 
and  GEOMETRIC  VOLUME  codes.  Use  FACILITY-LOCATION  to  link 
the  location  with  the  facility. 

22  items  map  to  FACILITY-TYPE  =  NOS  (60005,  60006,  60007, 
60047,  60051,  60054,  60055,  60056,  60062,  60066,  60070, 
60083, 60084,  60089,  60094,  60098,  60099,  60108,  60109, 
60136,  60141,  60147). 

TCDM  Notes: 

Obstacle  which  is  of  a  minor  nature  and  which  is  not  in¬ 
cluded  in  amore  specific  characterization. 

LC2IEDM  Notes: 

almost  maps  to  “Ohstacle  restricted  area”  or  to  “Obstacle  Belt”  or 
“Obstacle  Lane”  or  “Obstacle  Zone”. 

Computed  Degree  of  Alignment: 

30 

Native  Settlement^{CONTROL-FEATURE-TYPE,  GEOGRAPHIC-FEATURE-STATUS} 

Notes 

22  items  map  to  FACILITY-TYPE  =  NOS  (60005,  60006,  60007, 
60047, 60051,  60054,  60055,  60056,  60062,  60066,  60070, 
60083, 60084, 60089,  60094,  60098,  60099,  60108,  60109, 
60136,  60141,  60147). 

LC2IEDM  Notes: 

no  ECC  exists.  Could  map  to  “Named  area  of  interest”  or  many 
other  things  depending  on  how  it  was  being  used. 

Computed  Degree  of  Alignment: 

29 

Navigation  Aids  (Aeronautical)^{EQUIPMENT-TYPE} 

LC2IEDM  Notes: 

mapped  to  “Air-Traffic  Control  Radar”  ECC  ATCRAD  1000177 

Computed  Degree  of  Alignment: 

80 

Nuclear  Reactor^{EQUIPMENT-TYPE} 
Notes 

3  items  map  to  SITPWR  (60091,  60101,  60145). 

LC2IEDM  Notes: 

no  ECC  exists 

Computed  Degree  of  Alignment: 

57 

Offshore  Loading  Facility-^{FACILITY-TYPE} 

Notes 

transloading  facility? 

2  items  map  to  TRANSF  (60062,  60092). 

LC2IEDM  Notes: 

maps  to  “Transloading  Facility”  ECC  TRANSF  1000026 

Computed  Degree  of  Alignment: 

58 

Oil  /  Gas  Facilities^{FACILITY-TYPE,  GEOGRAPHIC-FEATURE-STATUS} 

Notes 

maps  to  3  different  codes 

LC2IEDM  Notes: 

mapped  to  “Depot,  POL”  ECC  DEPPOL  1000007. 
or  to  “POL  point”  ECC  POLPT  1000017 

Computed  Degree  of  Alignment: 

35 

Oil  /  Gas  Field^{FACILITY-TYPE,  GEOGRAPHIC-FEATURE-STATUS} 

Notes 

22  items  map  to  FACILITY-TYPE  =  NOS  (60005,  60006,  60007, 
60047,  60051,  60054,  60055,  60056,  60062,  60066,  60070, 
60083, 60084, 60089,  60094,  60098,  60099,  60108,  60109, 
60136,  60141,  60147). 

LC2IEDM  Notes: 

no  ECC  exists 

Computed  Degree  of  Alignment: 

23 
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Orchard  /  Plantation^{FACILITY-TYPE} 

Notes  2  items  map  to  ORD  (60095,  60159). 

LC2IEDM  Notes:  Maps  to  ORD,  Orchard/plantation  1000119. 

Computed  Degree  of  Alignment:  16 _ 

Pack  lce^{GEOGRAPHIC-FEATURE-TYPE} 

Notes  15  items  map  to  GEOGRAPHIC-FEATURE-TYPE  =  NOS  (60012, 

60015, 60052,  60076,  60096,  60100,  60115,  60116,  60131, 
60136,  60137,  60140,  60144,  60146,  60153,  60160). 
LC2IEDM  Notes:  no  ECC  exists. 

Computed  Degree  of  Alignment:  13 _ 

Pier  /  Wharf  /  Quay^{FACILITY-TYPE} 

Notes  harbor  or  port 

2  items  map  to  HARBUR  (60006,  60097). 

LC2IEDM  Notes:  mapped  to  “Harbour”  ECC  HARBUR  1000167 

Computed  Degree  of  Alignment:  38 _ 

Pile  /  Piling  /  Post^{FACILITY-TYPE} 

Notes  22  items  map  to  FACILITY-TYPE  =  NOS  (60005,  60006,  60007, 

60047,  60051,  60054,  60055,  60056,  60062,  60066,  60070, 
60083,  60084,  60089,  60094,  60098, 60099,  60108,  60109, 
60136,  60141,  60147). 

LC2IEDM  Notes:  no  ECC 

Computed  Degree  of  Alignment:  24 _ 

Pipeline  /  Pipe^{FACILITY-TYPE} 

Notes  22  items  map  to  FACILITY-TYPE  =  NOS  (60005,  60006,  60007, 

60047,  60051,  60054,  60055,  60056,  60062,  60066,  60070, 
60083,  60084,  60089,  60094,  60098,  60099,  60108,  60109, 
60136,  60141,  60147). 

LC2IEDM  Notes:  no  ECC  exists 

Computed  Degree  of  Alignment:  28 _ 

Polar  lce^{G EOG RAPH I C-FEATU RE-TYPE} 

Notes  15  items  map  to  GEOGRAPHIC-FEATURE-TYPE  =  NOS  (60012, 

60015,  60052,  60076,  60096,  60100, 60115,  60116, 60131, 
60136,  60137,  60140,  60144,  60146,  60153,  60160). 
LC2IEDM  Notes:  no  ECC  exists 

Computed  Degree  of  Alignment:  13 _ 

Power  Plant^{FACILITY-TYPE} 

Notes  3  items  map  to  SITPWR  (60091,  60101,  60145). 

LC2IEDM  Notes:  mapped  to  “Industrial  Installation”  ECC  INDINS  1000110. 

Computed  Degree  of  Alignment:  41 _ 

Power  Transmission  Line^{FACILITY-TYPE} 

Notes  2  items  map  to  PTL  (60102,  60103). 

LC2IEDM  Notes:  mapped  to  “Power  Transmission  Line”  ECC  PTL  1000120. 

Computed  Degree  of  Alignment:  52 _ 

Power  Transmission  Pylon^{FACILITY-TYPE} 

Notes  2  items  map  to  PTL  (60102,  60103). 

LC2IEDM  Notes:  no  ECC  exists. 

Computed  Degree  of  Alignment:  64 _ 
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Prepared  Defensive  Positions  Area^{CONTROL-FEATURE-TYPE} 

Notes  2  items  map  to  DEFPOS  (60043,  60104). 

LC2IEDM  Notes:  mapped  to  “Defensive  position”  ECC  DEFPOS  1000068. 

Computed  Degree  of  Alignment:  72 _ 

Prepared  Defensive  Region^{FACILITY-TYPE} 

Notes  fortified  area 

LC2IEDM  Notes:  mapped  to  “Defence  zone”  ECC  DEFZ  1000078 

Computed  Degree  of  Alignment:  100 _ 

Processing  Plant /Treatment  Plant^{FACILITY-TYPE} 

Notes  7  items  map  to  INDINS  (60011,  60013,  60026,  60106,  60107, 

60120,  60130). 

LC2IEDM  Notes:  mapped  to  “Industrial  Installation”  ECC  INDINS  1000110 

Computed  Degree  of  Alignment:  35 _ 

Pumping  Station^{FACILITY-TYPE} 

Notes  7  items  map  to  INDINS  (60011,  60013,  60026,  60106,  60107, 

60120,  60130). 

LC2IEDM  Notes:  mapped  to  “Industrial  Installation”  ECC  INDINS  1000110 

Computed  Degree  of  Alignment:  43 _ 

Quarry^{FACILITY-TYPE,  GEOGRAPHIC-FEATURE-STATUS} 

Notes  22  items  map  to  FACILITY-TYPE  =  NOS  (60005,  60006,  60007, 

60047,  60051,  60054,  60055,  60056,  60062,  60066,  60070, 
60083,  60084,  60089,  60094,  60098,  60099,  60108,  60109, 
60136,  60141,  60147). 

LC2IEDM  Notes:  no  ECC  exists. 

Computed  Degree  of  Alignment:  30 _ 

Race  Track^{FACILITY-TYPE} 

Notes  22  items  map  to  FACILITY-TYPE  =  NOS  (60005,  60006,  60007, 

60047,  60051,  60054,  60055,  60056,  60062,  60066,  60070, 
60083, 60084,  60089,  60094,  60098,  60099,  60108,  60109, 
60136,  60141,  60147). 

LC2IEDM  Notes:  no  ECC  exists. 

Computed  Degree  of  Alignment:  27 _ 

Railroad^{FACILITY-TYPE} 

Notes  1  item  maps  to  RWY 

LC2IEDM  Notes:  mapped  to  “Railway/railroad”  ECC  RWY  1000061. 

Computed  Degree  of  Alignment:  31 _ 

Railroad  Siding  /  Railroad  Spur^{FACILITY-TYPE} 

Notes  2  items  map  to  RAIL  (60112,  60113). 

LC2IEDM  Notes:  no  ECC  exists.  Oust  for  Railway/railroad). 

Computed  Degree  of  Alignment:  26 _ 

Railroad  Yard  /  Marshalling  Yard^{FACILITY-TYPE,  GEOGRAPHIC-FEATURE-STATUS} 

Notes  2  items  map  to  RAIL  (60112,  60113). 

LC2IEDM  Notes:  no  ECC  exists.  Oust  for  Railway/railroad). 

Computed  Degree  of  Alignment:  43 _ 

Railroad  Yard  /  Marshalling  Yard  Centerline  /  Nexus^{CONTROL-FEATURE-TYPE} 

Notes  Associated  with  the  railroad  yard  FACILITY  thru  FACILITY- 

LOCATION 
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LC2IEDM  Notes:  mapped  to  “Bearing  Line”  ECC  BERLIN  1000109. 

Computed  Degree  of  Alignment:  48 _ 

Railroad  in  Built-Up  Area  Centerline  /  Nexus^{CONTROL-FEATURE-TYPE} 

Notes  No  ECC  exists.  Can  associate  the  LOCATION  of  the  line  with 

the  railroad  FACILITY  thru  FACILITY-LOCATION. 

LC2IEDM  Notes:  mapped  to  “Bearing  Line”  ECC  BERLIN  1000109. 

Computed  Degree  of  Alignment:  26 _ 

Rapids^{GEOGRAPHIC-FEATURE-STATUS,  GEOGRAPHIC-FEATURE-TYPE} 

Notes  15  items  map  to  GEOGRAPHIC-FEATURE-TYPE  =  NOS  (60012, 

60015,  60052,  60076,  60096,  60100,  60115,  60116, 60131, 
60136,  60137,  60140,  60144,  60146,  60153,  60160). 
LC2IEDM  Notes:  no  ECC  exists. 

Computed  Degree  of  Alignment:  24 _ 

Reef^{GEOGRAPHIC-FEATURE-TYPE} 

Notes  15  items  map  to  GEOGRAPHIC-FEATURE-TYPE  =  NOS  (60012, 

60015, 60052, 60076,  60096,  60100,  60115,  60116,  60131, 
60136,  60137,  60140,  60144,  60146,  60153,  60160). 
LC2IEDM  Notes:  no  ECC  exists. 

Computed  Degree  of  Alignment:  19 _ 

Reservoir^{FACILITY-TYPE,  GEOGRAPHIC-FEATURE-STATUS} 

Notes  1  item  maps  to  RES 

LC2IEDM  Notes:  mapped  to  “Resevoir”  ECC  RES  1000121. 

Computed  Degree  of  Alignment:  37 _ 

Reservoir  Centerline  /  Nexus^{CONTROL-FEATURE-TYPE,  GEOGRAPHIC-FEATURE-STATUS} 

Notes  Associated  with  the  reservoir  FACILITY  thru  FACILITY- 

LOCATION. 

LC2IEDM  Notes:  mapped  to  “Bearing  Line”  ECC  BERLIN  1000109. 

Computed  Degree  of  Alignment:  34 _ 

Rice  Field^{FACILITY-TYPE} 

Notes  Although  there  is  no  FACILITY-TYPE-CATEGORY-CODE  for  Rice 

Field  in  LC2IEDM,  it  was  mapped  to  FACILITY-TYPE  as  it 
similar  to  Cropland  and  Orchard/Plantation  —  which  do  have 
a  FACILITY-TYPE-CATEGORY-CODE  (both  man  made  and  man¬ 
aged  or  controlled).  Adding  GEOGRAPHIC-FEATURE-STATUS- 
SURFACE-CONDITION-CODE  =  FLODNG  (Flooding),  it  gives  a 
good  representation  of  a  flooded  cropland. 

3  items  map  to  CRP  (60039,  60069,  60119). 

LC2IEDM  Notes:  Maps  to  CRP,  Cropland  1000115  or  ORD,  Orchard/plantation 

1000119. 

Computed  Degree  of  Alignment:  17 _ 

Rig  /  Superstructure^{EQUIPMENT-TYPE} 

Notes  7  items  map  to  INDINS  (60011,  60013,  60026,  60106,  60107, 

60120,  60130). 

LC2IEDM  Notes:  no  ECC  exists. 

Computed  Degree  of  Alignment:  43 _ 

River  /  Stream^{GEOGRAPHIC-FEATURE-STATUS,  GEOGRAPHIC-FEATURE-TYPE} 

LC2IEDM  Notes:  mapped  to  “River/stream”  ECC  RIV  1000051. 
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Computed  Degree  of  Alignment:  30 


River  /  Stream  Centerline  /  Nexus^{CONTROL-FEATURE-TYPE,  GEOGRAPHIC-FEATURE-STATUS} 

Notes 

The  LOCATION  line  can  be  associated  with  the  river  thru 
FEATURE-LOCATION,  FEATURE,  and  GEOGRAPHIC-FEATURE. 

LC2IEDM  Notes: 

mapped  to  “Bearing  Line”  ECC  BERLIN  1000109. 

Computed  Degree  of  Alignment: 

26 

Road^{FACILITY-TYPE,  GEOGRAPHIC-FEATURE-STATUS} 

Notes 

2  items  map  to  RD  (60025,  60123). 

LC2IEDM  Notes: 

mapped  to  “Road”  ECC  RD  1000058. 

Computed  Degree  of  Alignment: 

27 

Road  in  Built-Up  Area  Centerline  /  Nexus^{CONTROL-FEATURE-TYPE} 

Notes 

The  LOCATION  line  is  associated  with  the  road  thru  FACILITY- 
LOCATION  and  FACILITY. 

LC2IEDM  Notes: 

mapped  to  “Bearing  Line”  ECC  BERLIN  1000109. 

Computed  Degree  of  Alignment: 

33 

Rock  Strata  /  Rock  Formation^{GEOGRAPHIC-FEATURE-TYPE} 

Notes 

2  items  map  to  RST  (60050,  60125). 

LC2IEDM  Notes: 

mapped  to  “Rock  strata/Rock  formation”  ECC  RST  1000052. 

Computed  Degree  of  Alignment: 

36 

Route  (Maritime)^{CONTROL-FEATURE-TYPE} 

LC2IEDM  Notes: 

mapped  to  “Route”  ECC  ROUTE  1000050. 

Computed  Degree  of  Alignment: 

44 

Route  (Maritime)  Centerline  /  Nexus^{CONTROL-FEATURE-TYPE} 

LC2IEDM  Notes: 

mapped  to  “Bearing  Line”  ECC  BERLIN  1000109. 

Computed  Degree  of  Alignment: 

50 

Ruins^{FACILITY-TYPE} 

Notes 

There  is  a  FACILITY-TYPE-CATEGORY-CODE  for  this  in 
LC2IEDM. 

LC2IEDM  Notes: 

Maps  to  RUI,  Ruins  1999122. 

Computed  Degree  of  Alignment: 

56 

Runway^{FACILITY-TYPE,  GEOGRAPHIC-FEATURE-STATUS} 

Notes 

airstrip 

4  items  map  to  AIR  (60003,  60004,  60129,  60146). 

LC2IEDM  Notes: 

mapped  to  “Airfield/airport/airstrip”  ECC  AIR  1000037. 

Computed  Degree  of  Alignment: 

39 

Salt  Evaporator^{FACILITY-TYPE} 
Notes 

7  items  map  to  INDINS  (60011,  60013,  60026,  60106,  60107, 
60120,  60130). 

LC2IEDM  Notes: 

mapped  to  “Industrial  Installation”  ECC  INDINS  1000110. 

Computed  Degree  of  Alignment: 

14 

Salt  Pan^{GEOGRAPHIC-FEATURE-TYPE} 

Notes 

15  items  map  to  GEOGRAPHIC-FEATURE-TYPE  =  NOS  (60012, 
60015, 60052,  60076,  60096,  60100,  60115,  60116,  60131, 
60136,  60137,  60140,  60144,  60146,  60153,  60160). 

LC2IEDM  Notes: 

no  ECC  exists. 

Computed  Degree  of  Alignment: 

12 
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Sand  Dune  /  Sand  Hills^{GEOGRAPHIC-FEATURE-TYPE} 

LC2IEDM  Notes: 

mapped  to  “Sand  dune/sand  hill”  ECC  SND  1000057. 

Computed  Degree  of  Alignment: 

24 

Scrub  /  Brush  /  Bush^{GEOGRAPHIC-FEATURE-TYPE} 

LC2IEDM  Notes: 

mapped  to  “Scrub/brush”  ECC  SCR  1000055. 

Computed  Degree  of  Alignment: 

27 

Seawall^{FACILITY-TYPE} 

Notes 

2  items  map  to  WALL  (60161,  60134). 

LC2IEDM  Notes: 

mapped  to  “Wall”  ECC  WALL  1000087. 

Computed  Degree  of  Alignment: 

38 

Sebkha^{GEOGRAPHIC-FEATURE-TYPE} 

Notes 

2  items  map  to  DPR  (60135,  60149). 

LC2IEDM  Notes: 

mapped  (poorly)  to  “Depression”  ECC  DPR  1000022. 

Computed  Degree  of  Alignment: 

18 

Settlement^{CONTROL-FEATURE-TYPE} 

Notes 

22  items  map  to  FACILITY-TYPE  =  NCS  (60005,  60006,  60007, 
60047, 60051,  60054,  60055,  60056,  60062,  60066,  60070, 
60083, 60084,  60089,  60094,  60098,  60099,  60108,  60109, 
60136,  60141,  60147). 

LC2IEDM  Notes: 

mapped  (vaguely)  to  “Area  of  Interest”  ECC  ACI  1000003 

Computed  Degree  of  Alignment: 

29 

Settling  Basin  /  Sludge  Pond^{GEOGRAPHIC-FEATURE-STATUS,  GEOGRAPHIC-FEATURE-TYPE} 

Notes 

15  items  map  to  GECGRAPHIC-FEATURE-TYPE  =  NCS  (60012, 
60015,  60052,  60076,  60096,  60100,  60115,  60116,  60131, 
60136,  60137,  60140,  60144,  60146,  60153,  60160). 

LC2IEDM  Notes: 

no  ECC  exists. 

Computed  Degree  of  Alignment: 

21 

Snow  Field  /  Ice  Field^{GEOGRAPHIC-FEATURE-STATUS,  GEOGRAPHIC-FEATURE-TYPE} 

Notes 

15  items  map  to  GECGRAPHIC-FEATURE-TYPE  =  NCS  (60012, 
60015,  60052,  60076,  60096,  60100,  60115,  60116,  60131, 
60136,  60137,  60140,  60144,  60146,  60153,  60160). 

LC2IEDM  Notes: 

no  ECC  exists. 

Computed  Degree  of  Alignment: 

14 

Snow  Shed  /  Rock  Shed^{FACILITY-TYPE} 

Notes 

A  hut  is  a  small  simple  or  crude  house  or  shelter.  It  is  dis¬ 
tinguished  from  the  term  shed,  which  is  used  for  storage. 
The  definition  of  snow  shed/  rock  shed  implies  it  is  used  to 
shelter  people  or  things  from  falling  dehris. 

LC2IEDM  Notes: 

mapped  to  “Huf’  ECC  HUT 

Computed  Degree  of  Alignment: 

76 

Spring  /  Water  Hole^{GEOGRAPHIC-FEATURE-TYPE} 

Notes 

15  items  map  to  GECGRAPHIC-FEATURE-TYPE  =  NCS  (60012, 
60015, 60052,  60076,  60096, 60100,  60115,  60116,  60131, 
60136,  60137,  60140,  60144,  60146,  60153,  60160). 

LC2IEDM  Notes: 

no  ECC  exists. 

Computed  Degree  of  Alignment: 

24 

stadium /Amphitheatre^{FACILITY-TYPE,  GEOGRAPHIC-FEATURE-STATUS} 
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Notes  22  items  map  to  FACILITY-TYPE  =  NOS  (60005,  60006,  60007, 

60047, 60051,  60054,  60055,  60056,  60062,  60066,  60070, 
60083,  60084,  60089,  60094,  60098,  60099,  60108, 60109, 
60136,  60141,  60147). 

LC2IEDM  Notes:  no  ECC  exists. 

Computed  Degree  of  Alignment:  31 _ 

Storage  Bunker  /  Storage  Mound^{FACILITY-TYPE} 

LC2IEDM  Notes:  mapped  to  “Bunker”  ECC  BUNKER  1000023 

Computed  Degree  of  Alignment:  68 _ 

Storage  Tank^{FACILITY-TYPE} 

Notes  2  items  map  to  DEPOT  (60045,  60143). 

LC2IEDM  Notes:  mapped  (roughly)  to  “Depot,  not  otherwise  specified”  ECC  DEPOT 

1000046. 

Computed  Degree  of  Alignment:  57 _ 

Submerged  Rock^{GEOGRAPHIC-FEATURE-TYPE} 

Notes  15  items  map  to  GEOGRAPHIC-FEATURE-TYPE  =  NOS  (60012, 

60015,  60052,  60076,  60096,  60100,  60115,  60116, 60131, 
60136,  60137,  60140,  60144,  60146,  60153,  60160). 
LC2IEDM  Notes:  no  ECC  exists. 

Computed  Degree  of  Alignment:  32 _ 

Substation  /  Transformer  Yard^{FACILITY-TYPE} 

Notes  3  items  map  to  SITPWR  (60091,  60101,  60145). 

TCDM  Notes:  A  structure  or  group  of  structures,  along  a  power  line 

route,  in  which  electric  current  is  transformed  and/or  dis¬ 
tributed. 

LC2IEDM  Notes:  Mapped  to  “Site,  Power”  ECC  SITPWR,  a  power  production  or 

distribution  installation. 

Computed  Degree  of  Alignment:  46 _ 

Taxiway^{FACILITY-TYPE,  GEOGRAPHIC-FEATURE-STATUS} 

Notes  4  items  map  to  AIR  (60003,  60004,  60129,  60146). 

LC2IEDM  Notes:  mapped  to  “Airfield/airport/airstrip”  ECC  AIR  1000037. 

Computed  Degree  of  Alignment:  25 _ 

Telephone  Line  /  Telegraph  Line^{FACILITY-TYPE} 

Notes  22  items  map  to  FACILITY-TYPE  =  NOS  (60005,  60006,  60007, 

60047,  60051,  60054,  60055,  60056,  60062,  60066,  60070, 
60083, 60084,  60089,  60094,  60098,  60099,  60108,  60109, 
60136,  60141,  60147). 

LC2IEDM  Notes:  no  ECC  exists. 

Computed  Degree  of  Alignment:  40 _ 

Terrain  Cut^{GEOGRAPHIC-FEATURE-TYPE} 

Notes  15  items  map  to  GEOGRAPHIC-FEATURE-TYPE  =  NOS  (60012, 

60015,  60052,  60076,  60096,  60100, 60115,  60116, 60131, 
60136,  60137,  60140,  60144,  60146,  60153,  60160). 
LC2IEDM  Notes:  no  ECC  exists. 

Computed  Degree  of  Alignment:  26 _ 

Terrain  Depression^{GEOGRAPHIC-FEATURE-TYPE} 

Notes  2  items  map  to  DPR  (60135,  60149). 
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LC2IEDM  Notes:  mapped  to  “Depression”  ECC  DPR  1000022. 

Computed  Degree  of  Alignment:  30 _ 


Tower  (Non-communication)^{FACILITY-TYPE} 

Notes 

2  items  map  to  TOW  (only)  (only)  (60037,  60150). 

LC2IEDM  Notes: 

mapped  to  “Tower,  non-communication”  ECC  TOW  1000124. 

Computed  Degree  of  Alignment: 

57 

Trail^{CONTROL-FEATURE-TYPE,  GEOGRAPHIC-FEATURE-STATUS} 

LC2IEDM  Notes: 

no  ECC  exists. 

Computed  Degree  of  Alignment: 

27 

Trees^{GEOGRAPHIC-FEATURE-TYPE} 

LC2IEDM  Notes: 

mapped  to  “Tree”  ECC  TRE  1000064. 

Computed  Degree  of  Alignment: 

22 

Tundra^{GEOGRAPHIC-FEATURE-TYPE} 

Notes 

15  items  map  to  GEOGRAPHIC-FEATURE-TYPE  =  NOS  (60012, 
60015, 60052,  60076,  60096,  60100,  60115,  60116,  60131, 
60136,  60137,  60140,  60144,  60146,  60153,  60160). 

LC2IEDM  Notes: 

no  ECC  exists. 

Computed  Degree  of  Alignment: 

10 

Tunnel^{FACILITY-TYPE} 

Notes 

There  is  a  FACILITY-TYPE-CATEGORY-CODE  for  this  in 
LC2IEDM. 

LC2IEDM  Notes: 

Maps  to  TUN,  Tunnel  1000067. 

Computed  Degree  of  Alignment: 

78 

Tunnel  Shelter^{FACILITY-TYPE} 
Notes 

2  items  map  to  SHLUND  (60155,  60156). 

LC2IEDM  Notes: 

mapped  to  “Shelter,  underground”  ECC  SHLUND  1000071. 

Computed  Degree  of  Alignment: 

72 

Underground  Bunker^{FACI  LITY-TYPE} 
Notes 

2  items  map  to  SHLUND  (60155,  60156). 

LC2IEDM  Notes: 

mapped  to  “Shelter,  underground”  ECC  SHLUND  1000071. 

Computed  Degree  of  Alignment: 

57 

Underwater  Danger  /  Hazard^{CONTROL-FEATURE-TYPE} 

Notes 

3  items  map  to  CONTROL-FEATURE-TYPE  =  NOS  (60044,  60059, 
60157). 

LC2IEDM  Notes: 

no  ECC  exists. 

Computed  Degree  of  Alignment: 

25 
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Vehicle  Barrier^{FACILITY-TYPE} 

Notes  Can  be  mapped  to  5  different  codes  within  FACILITY- TYPE; 

ROADBL  “Roadblock”  (a  barrier  or  obstacle  (usually  covered  by 
fire)  used  to  block,  or  limit  the  movement  of,  hostile  vehi¬ 
cles  along  a  route),  ABATIS  (a  vehicular  obstacle  constructed 
by  felling  trees),  DGT  “Dragon  Teeth”  (regular  spaced  concrete 
or  metal  barriers  laid  in  a  single  or  multiple  rows  to  pre¬ 
vent  vehicular  movement),  ANTOBS  “Anti-Tank  Obstacle”, 
(no  definition  given),  BPSOBS  “Beam  Post  Obstacle”  (a  squared- 
off  log  or  a  large,  oblong  piece  of  timber,  metal,  or  stone 
inserted  in  the  ground  to  obstruct  movement.) 

TCDM  Notes:  A  permanent  or  semi-permanent  obstruction  placed  across 

a  route  to  prevent  vehicular  traffic. 

LC2IEDM  Notes:  maps  best  to  “Roadblock”  ECC  ROADBL. 

could  also  map  to  “Anti-tank  Obstacle”  ECC  ANTOBS  1000132. 

Or  to  “Beam  post  obstacle”  ECC  BPSOBS  1000126. 

Or  to  “Abatis”  ECC  ABATIS. 

Or  to  “Dragon  Teeth”  ECC  DGT. 

Computed  Degree  of  Alignment:  94 _ 

Vineyards^{FACILITY-TYPE,  GEOGRAPHIC-FEATURE-STATUS} 

Notes  2  items  map  to  ORD  (60095,  60159). 

LC2IEDM  Notes:  Maps  to  ORD,  Orchard/plantation  1000119. 

Computed  Degree  of  Alignment:  25 _ 

Volcanic  Dike^{GEOGRAPHIC-FEATURE-TYPE} 

Notes  15  items  map  to  GEOGRAPHIC-FEATURE-TYPE  =  NOS  (60012, 

60015,  60052,  60076,  60096,  60100, 60115,  60116, 60131, 
60136,  60137,  60140,  60144,  60146,  60153,  60160). 

LC2IEDM  Notes:  no  ECC  exists. 

Computed  Degree  of  Alignment:  26 _ 


Windmill^{FACILITY-TYPE} 

LC2IEDM  Notes:  Maps  to  WML,  Windmill  1000125 

Computed  Degree  of  Alignment:  85 _ 
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Zone  of  Occupation^{CONTROL-FEATURE-TYPE} 

Notes 

Zone  of  Occupation  would  be  a  geographic  subset  of,  and 
included  within,  the  LC2IEDM's  “Area  of  Interest”. 

TCDM  Notes: 

An  area  temporarily  held  and  controlled  by  a  foreign  mili¬ 
tary  force. 

LC2IEDM  Notes: 

Maps  to  “Area  of  Interesf’  ECC  AOI,  A  CONTROL-FEATURE-TYPE 
with  an  area  location  which  denotes  that  area  of  concern  to 
the  commander,  including  the  area  of  influence,  and  ex¬ 
tending  into  enemy  territory  to  the  objectives  of  current  or 
planned  operations.  This  area  also  includes  areas  occu¬ 
pied... 

Computed  Degree  of  Alignment: 

67 

D.2  LC2IEDM-to-TCDM  Alignment  Results 

This  section  presents  results  of  assessing  the  degree  to  which  the  LC2IEDM  aligns  to  the 
TCDM.  The  LC2IEDM  has  two  entities  that  model  terrain  concepts:  GEOGRAPHIC- 
FEATURE  and  FACILITY.  Because  these  are  distinct  entities  with  individual  attributes,  we 
opted  to  assess  terrain  alignment  by  modeling  each  as  a  separate  concept.  We  therefore 
performed  two  Conceptual-level  alignment  assessments  with  respect  to  terrain.  Each  is 
presented  in  a  separate  section. 

D.2.1  Geographic  Feature 

This  section  presents  results  of  assessing  the  degree  to  which  EC2IEDM  entities  related 
to  geographic  features  align  to  the  TCDM.  The  following  notes  were  made  on  Concep¬ 
tual-level  alignment: 

Notes:  The  JSIMS  terrain  view  is  somewhat  broader  than  neces¬ 

sary.  It  includes  man-made  features,  which  aren't  part  of 
geographic  features.  But  better  too  much  than  too  little. 

The  attached  document  describes  how  LC2IEDM  terrain 
data  maps  to  the  TCDM. 

Computed  Degree  of  Alignment:  63 _ 

The  following  table  presents  the  results  of  Entity-level  assessment  for  each  EC2IEDM 
entity  of  the  Geographic  Eeature  concept. 

Table  D-2.  Geographic  Feature  Assessment  Summaries 
CONTROL-FEATURE^h 

Notes  It  would  seem  that  TCDM  offers  several  ECCs  that  relate 

to  the  various  control  features  that  the  LC2IEDM  can 
model.  However,  the  ECCs  have  no  attributes  that  identify 
them  as  related;  the  alignment  will  be  structural,  based  on 
relationship  of  an  ECC  name  to  a  category  code. 

LC2IEDM  Notes:  From  the  Geographic  Feature  view. 

Computed  Degree  of  Alignment:  75 _ 

CONTROL-FEATURE-GEOGRAPHIC-FEATURE-ASSOCIATION^h 

Notes  The  CONTROL-FEATURE-GEOGRAPHIC-FEATURE-ASSOCIATION 

entity  describes  the  relationship  between  a  control  feature 
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means  that  one  geographic  feature  type  can  he  the  type  of 
multiple  geographic  features.  It  may  also  denote  that  one 
geographic  feature  has  multiple  types,  although  that  rela¬ 
tionship  seems  unlikely. 

The  TCDM  does  not  easily  model  even  the  l:n  mapping. 
LC2IEDM  Notes:  From  the  Geographic  Feature  view. 

Computed  Degree  of  Alignment:  50 _ 

OBJECT-TYPE^O 

Notes  In  the  context  of  the  Geographic  Feature  view,  OBJECT-TYPE 

doesn't  play  much  role.  Rather,  its  suhtype  GEOGRAPHIC- 
FEATURE  is  used  to  model  various  kinds  of  terrain  features. 
LC2IEDM  Notes:  From  the  Geographic  Feature  view. 

Computed  Degree  of  Alignment:  75 _ 

D.2.2  Conceptual-Level  Alignment  of  Facility 

This  section  presents  results  of  assessing  the  degree  to  which  LC2IEDM  entities  related 
to  facilities  align  to  the  TCDM.  The  following  notes  were  made  on  Conceptual-level 
alignment: 


Notes: 

The  JSIMS  terrain  view  is  somewhat  broader  than  neces¬ 
sary.  It  includes  geographic  (natural)  features,  which 
aren't  part  of  facilities.  But  better  too  much  than  too  little. 

The  JSIMS  Facility  view  models  man-made  facilities.  It 
probably  overlaps  with  the  Terrain  view. 

The  attached  document  describes  how  LC2IEDM  facility 
data  maps  to  the  TCDM. 

Assigned  Degree  of  Alignment: 

100 

The  following  table  presents  the  results  of  Entity-level  assessment  for  each  EC2IEDM 
entity  of  the  Eacility  concept. 

Table  D-3.  Facility  Assessment  Summaries 


BRIDGE^{Bridge  /  Overpass  /  Viaduct,  Bridge  Span} 

Notes 

A  BRIDGE  is  a  subtype  of  FACILITY.  The  degree  of  alignment 
of  BRIDGE  depends  upon  the  degree  to  which  FACILITY  aligns. 

Both  the  LC2IEDM  and  the  TCDM  include  the  concept  of  a 
bridge.  In  the  TCDM  a  bridge  is  a  complex  type. 

Computed  Degree  of  Alignment: 

64 
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FACILITY^{Aircraft  Maintenance  Shop,  Airport /Airfield,  Airstrip,  Barracks,  Bridge  /  Overpass  /  Viaduct,  Building, 

Built  Up  Area,  Bunker,  Burial  Grounds,  Camp,  Canal,  Cemetery,  Chimney  /  Smokestack,  Cleared  Way  /  Cut  Line  / 
Firebreak,  Communication  Building,  Communication  Tower,  Control  Tower,  Cropland,  Crossing,  Dam  /  Weir, 
Decontamination  Pad,  Depot  (Storage),  Ditch  and/or  Berm,  Engineered,  Dragon  Teeth,  Early  Warning  Radar  Site, 
Fence,  Ferry  Site,  Fort,  Fortification,  Gate,  Harbour,  Helicopter  Landing  Pad,  Heliport,  Hospital  Building,  Hut,  Industrial 
Building,  Industrial  Complex  (Heavy),  Industrial  Complex  (Light),  Industrial  Works,  Infantry  Trench,  Interchange, 

Military  Trench,  Minefield,  Miscellaneous  Cbstacle,  Missile  Site,  Cffshore  Loading  Facility,  Crchard  /  Plantation, 

Parking  Garage,  Port  Facility  Power  Transmission  Line,  Prepared  Raft  or  Float  Bridge  Site,  Railroad,  Refugee 
Compound,  Reservoir,  Revetment  (Shore  Protection),  Road,  Ruins,  Shed,  Station,  Steeple,  Terrain  Crater,  Terrain 

Cut,  Tower  (Non-communication),  Tunnel, 

Underground  Bunker,  Wall,  Water  Tower 

Notes 

Each  LC2IEDM  instance  of  a  facility  will  be  represented  as 
some  TCDM  ECC.  The  degree  of  alignment  depends  upon 
how  many  types  of  facilities  can  be  modeled  by  TCDM 
ECCs. 

Deb  identified  the  following  ECCs  that  aren't  in  the  TCDM 
DB:  Tower  (non-communications),  Watering  Place,  Wire  Cbstacle. 

LC2IEDM  Notes: 

From  the  Facility  view. 

Computed  Degree  of  Alignment: 

88 

FACILITY-STATUS^O 

Notes 

FACILITY-STATUS  aligns  to  the  degree  that  the  TCDM  can 
record  status  information  about  a  facility. 

LC2IEDM  Notes: 

From  the  Facility  view. 

Computed  Degree  of  Alignment: 

13 

FACILITY-TYPE^IAirport /Airfield,  Bridge  /  Cverpass  /  Viaduct,  Building,  Built  Up  Area,  Canal,  Chimney/ 
Smokestack,  Cleared  Way  /  Cut  Line  /  Firebreak,  Communication  Building,  Communication  Tower,  Control  Tower, 
Cropland,  Dam  /  Weir,  Depot  (Storage),  Heliport,  Infantry  Trench,  Minefield,  Miscellaneous  Cbstacle,  Cffshore 

Loading  Facility  Crchard  /  Plantation,  Power  Transmission  Line,  Railroad,  Reservoir,  Road,  Ruins,  Terrain  Cut, 

Tunnel,  Underground  Bunker,  Wall,  Water  Tower,  Windmill} 

Notes 

The  FACILITY-TYPE  entity  describes  the  type  of  facility  and 
therefore  aligns  closely  to  the  TCDM  ECCs,  albeit  struc¬ 
turally. 

LC2IEDM  Notes: 

From  the  Facility  view. 

Computed  Degree  of  Alignment: 

78 

MINEFIELD^IMinefield} 

Computed  Degree  of  Alignment: 

57 

CBJECT-ITEM^O 

Notes 

In  the  context  of  the  Facility  view,  an  CBJECT-ITEM  instance 
represents  the  information  about  a  facility  that  is  inde¬ 
pendent  of  facility-specific  characteristics.  The  degree  of 
alignment  of  an  CBJECT-ITEM  depends  upon  the  degree  to 
which  the  TCDM  models  this  same  type  of  information. 

LC2IEDM  Notes: 

From  the  Facility  view. 

Computed  Degree  of  Alignment: 

80 

CBJECT-ITEM-STATUS^O 

Notes 

CBJECT-ITEM-STATUS  records  general  status  information.  The 
TCDM  does  not  model  this  type  of  information  well. 

LC2IEDM  Notes: 

From  the  Facility  view. 

Computed  Degree  of  Alignment: 

20 

OBJECT-ITEM-TYPE^O 
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Notes 

In  the  context  of  the  Facility  view,  the  OBJECT-ITEM-TYPE 
entity  models  the  many-to-many  relationships  that  can 
exist  between  facilities  and  facility  types.  The  TCDM  does 
not  model  these  many-to-many  relationships  well.  At  hest, 
it  can  model  one-to-many  relationships. 

LC2IEDM  Notes: 

From  the  Facility  view. 

Assigned  Degree  of  Alignment: 

50 

OBJECT-TYPE^O 

Notes 

In  the  context  of  the  Facility  view,  the  OBJECT-TYPE  entity 
records  type  information  that  is  not  specific  to  a  facility. 

LC2IEDM  Notes: 

From  the  Facility  view. 

Computed  Degree  of  Alignment: 

80 
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Appendix  E.  Rules  for  Value-Level  Assessments 


This  appendix  presents  the  rules  assessors  followed  to  perform  Value-level  alignment  as¬ 
sessments.  The  rules  were  introdueed  to  codify  procedures  and  techniques.  The  intent 
was  to  ensure  that  degrees  of  alignment  were  uniformly  and  repeatably  derived. 

E.l  Background 

Value-level  alignments  describe  relationships  between  atomic  domains  in  JSIMS  and 
LC2IEDM.  In  this  context,  “atomic”  means  indivisible.  No  JSIMS  attribute  whose  value 
is  a  complex  data  type  is  included.  All  LC2IEDM  attributes  are  atomic. 

E.2  JSIMS  Atomic  Domains 

In  JSIMS,  there  are  two  kinds  of  atomic  domains:  predefined  and  user-defined.  The  pre¬ 
defined  domains  used  in  JSIMS  are  those  based  on  existing  data  types  from  number  the¬ 
ory  and  programming  languages,  and  standardized  through  the  External  Data  Representa¬ 
tion  (XDR)  standard.  The  following  is  a  list  of  the  predefined  types  used  in  the  JSIMS 
Version  6  EOM: 

boolean  A  4-byte  integer.  An  instance  of  the  type  may  have  a  value  of  either  0 

or  1,  corresponding  to  the  logical  values  false  and  true. 

char  Not  really  a  domain,  but  instead  indicates  a  placeholder  for  future  ca¬ 

pabilities. 

double  An  8-byte  IEEE  double-precision  floating-point  number.  Its  range  is 

±2^°^^ ,  and  it  has  about  17  significant  decimal  digits. 

float  A  4-byte  IEEE  single-precision  floating-point  number.  Its  range  is 

±  2'^’ ,  and  it  has  about  7  significant  decimal  digits. 

long  A  4-byte  integer  in  two’s  complement  notation,  meaning  it  can  repre¬ 

sent  values  from  -2^'  to  2^'  -1 . 

octet  A  placeholder  for  buffer  data  when  shuttling  values  around  a  EOM  in 

the  HEA. 

string  A  string  of  arbitrary  length  (although  the  length  of  an  instance  is 

fixed). 

unsigned  long  ^  4-byte  integer,  values  of  which  can  range  from  0  to  2^^  - 1 . 

There  are  no  attributes  published  by  WARSIM  whose  type  is  float,  octet,  or  unsigned  long. 
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The  atomic  user-defined  JSIMS  domains  are  the  enumerated  data  types.  An  enumerated 
data  type  is  represented  as  a  4-byte  integer.  It  can  therefore  have  up  to  2^^  - 1  distinct 
values. 

E.3  LC2IEDM  Atomic  Domains 

In  the  LC2IEDM,  every  attribute  includes  a  specification  of  its  representation  in  a  physi¬ 
cal  database.  This  is  its  domain.  Unlike  JSIMS,  then,  all  attributes  have  atomic  domains. 

The  domains  used  in  the  LC2IEDM  are  drawn  from  the  ANSI  SQE  specification.  They 
are  as  follows: 

CHAR(6)  A  string  exactly  six  characters  long,  i.e.,  when  stored  in  the  data¬ 

base  it  occupies  6  characters’  worth  of  space.  This  domain  is 
used  to  store  the  attributes  whose  names  end  in  “-CODE”,  i.e., 
domains  that  correspond  to  enumerated  codes. 

NUMBER(cf)  integer  with  d  decimal  digits,  i.e.,  between  -10"'-l-l  and 

10"^  -1 .  This  domain  is  used  to  store  quantities  (e.g.,  number  of 
items  held).  It  is  also  used  to  store  entity  identifiers:  NUMBER(12), 
NUMBER(15),  and  NUMBER(18)  are  the  characteristic  declarations 
for  an  attribute  whose  name  ends  with  “-ID”. 

NUMBER(cf,s)  A  fixed-point  number  with  d  decimal  digits,  s  of  which  are  after 
the  decimal  point.  This  domain  is  typically  used  to  store  physical 
measurements.  Eor  example,  a  latitude,  which  is  measured  in  de¬ 
grees,  is  stored  as  NUMBER(9,6).  That  means  a  latitude  stored  us¬ 
ing  the  EC2IEDM  can  be  resolved  to  about  1 1  cm. 

The  EC2IEDM  stores  all  real  quantities  as  fixed-point  numbers. 
No  EC2IEDM  attributes  have  a  floating-point  domain. 

VARCHAR(n)  A  string  that  may  be  up  to  n  characters  long,  i.e.,  when  stored  in 

the  database  it  occupies  no  more  than  n  characters’  worth  of 
space,  and  less  if  its  length  is  less  than  n.  This  domain  is  typi¬ 
cally  used  to  record  descriptive  text,  either  in  phrases  (where  n  is 
fairly  small)  or  large  text  blocks  (where  n  may  be  as  large  as 
2000). 

E.4  Rules  for  Performing  Value-Level  Alignment 
Assessments 

This  section  describes  how  to  perform  a  Value-level  alignment  assessment.  The  subsec¬ 
tions  are  organized  by  the  types  of  domains  used  in  JSIMS.  The  key  questions  for  asses¬ 
sors  to  keep  in  mind  as  they  perform  a  Value-level  assessment  are: 

1 .  Can  the  EC2IEDM  represent  data  that  a  JSIMS  federate  might  generate? 

2.  Can  a  JSIMS  federate  restore  its  state  using  that  data? 
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A  Value-level  assessment  is  derived  from  a  State-level  assessment.  When  an  assessor  per¬ 
forms  a  Value-level  assessment,  he  has  already  determined  that  there  exists  JSIMS  attrib¬ 
ute  y'a  of  type  jt  and  that y'a  is  aligned  with  an  LC2IEDM  attribute  4  whose  type  (represen¬ 
tation  in  physieal  database)  is  k}  Knowledge  of  ja  and  its  purpose  is  often  vital  in  per¬ 
forming  Value-level  assessments.  For  example,  if y'a  stores  a  latitude,  its  value  is  limited  to 
±90. 

E.4.1  Rules  for  Enumerated  Domains 

If  jt  is  an  enumerated  type  (e.g.,  country_codes_enum_e),  then  there  must  exist  a  mapping 
from  each  element  of  the  enumeration  to  an  LC2IEDM  attribute  value.  The  following 
rules  apply. 

3.  If  7a  aligns  to  exactly  one  EC2IEDM  attribute  whose  domain  is  k,  and  k  is  also  an 
enumerated  type,  then  the  degree  of  alignment  is  the  percent  of  JSIMS  values  that 
have  EC2IEDM  equivalents.  To  calculate  this  quantity: 

a)  Define,  insofar  as  possible,  an  unambiguous  mapping  from  jt  to  k.  The  enumerated 
values  do  not  have  to  be  the  same  in  both  types;  it  is  only  necessary  that  a  map¬ 
ping  exist. 

For  example,  consider  the  JSIMS  type  country_codes_enum_e.  During  State  level  as¬ 
sessment,  we  may  find  that  some  JSIMS  attribute  ja  of  type  country_codes_enum_e 
aligns  to  the  EC2IEDM  attribute  OBJECT-TYPE-NATIONALITY-CODE.  To  derive  a 
Value  level  assessment  from  ja,  we  study  the  overlapping  values  between  and 
OBJECT-TYPE-NATIONALITY-CODE.  As  it  happens,  country_codes_enum_e  has  only  one 
value:  cntry_un known.  OBJECT-TYPE-NATIONALITY-CODE  has  273  values.  One  of  these 
values  is  NOS  (Not  Otherwise  Specified,  meaning  not  in  the  known  list  of  coun¬ 
tries),  which  conveys  the  same  information  as  cntry_unknown. 

b)  Compute  the  degree  of  alignment  as  the  number  of  items  in  the  mapping  divided 
by  the  number  of  items  in  jt. 

Continuing  our  example,  the  degree  of  alignment  between  country_codes_enum_e 
and  the  values  of  OBJECT-TYPE-NATIONALITY-CODE  is  1/1,  or  100%. 

4.  Sometimes  ja  aligns  to  multiple  EC2IEDM  attributes.  The  Value-level  degree  of  align¬ 
ment  is  still  the  percent  of  JSIMS  enumerated  values  that  can  be  mapped  to 
EC2IEDM  attribute  values,  but  the  analysis  is  more  complicated  because  of  the  need 
to  determine  (and  document!)  dependency  relationships. 

For  example,  the  JSIMS  attribute  comms_status_receive,  which  is  of  type 
equipment_sensor_status_e,  aligns  to  2  FC2IEDM  attributes:  MATERIEL-STATUS- 
OPERATIONAL-STATUS-CODE  and  MATERIEL-STATUS-USAGE-STATUS-CODE.  The  value  of 
the  second  attribute  depends  on  the  value  of  the  first. 

To  calculate  the  Value  level  degree  of  alignment  requires  understanding  these  de¬ 
pendencies.  The  equipment_sensor_status_e  type  has  4  values:  damaged,  jammed, 
off_status,  and  on_status.  Table  E-1  describes  relationships  between  these  values  and  the 
FC2IEDM  MATERIEL-STATUS-OPERATIONAL-STATUS-CODE  values. 


This  is  simplified.  There  are  some  counterexamples  below. 
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Table  E-1.  Equipment  Status  Enumerations  Mapping 


JSIMS  Value 

LC2IEDM  Values 

Notes 

damaged 

•  NOP  (not  operational) 

•  MOPS  (marginally 
operational) 

It  seems  logical  that  damaged  equipment 
would  be  considered  marginally  operational. 

jammed 

None 

LC2IEDM  does  have  a  TNOPS  (temporarily 
not  operational)  value.  But  it  does  not  seem 
sufficient  to  model  jamming. 

off  status 
on_status 

•  OPR  (fully  operational) 

•  SOPR  (substantially 
operational) 

•  OPR  and  SOPR  do  not  exactly  model 
off_status  or  on_status.  They  only  model  the 
capability  for  the  equipment  to  he  on  or 
off. 

•  The  LC2IEDM  provides  no  precise 
definition  of  “suhstantially  operational”.  I 
assume  it  means  the  equipment  can  still 
he  turned  on  and  off,  and  that  it  does  not 
qualify  as  damaged. 

If  the  equipment  is  damaged,  jammed,  or  off,  then  the  value  of  the  MATERIEL-STATUS- 
USAGE-STATUS-CODE  attribute  will  be  DEACTV  (deaetivated).  If  the  equipment  is  on, 
then  the  attribute’s  value  will  be  ACTIVE  (aetivated). 

We  have  mapped  three  out  of  the  four  values  of  equipment_sensor_status_e.  We  therefore 
compute  the  degree  of  alignment  to  be  75%. 

Note  that  the  mapping  is  not  1 : 1  or  even  n;  1 .  We  have  identified  two  possible  values 
for  damaged.  To  implement  this  mapping,  we  would  choose  one  (since  JSIMS  lacks 
the  resolution  of  LC2IEDM).  If  a  JSIMS  federate  wanted  to  store  data  about  damaged 
communication  equipment,  it  would  use  (say)  NOP.  If  it  wanted  to  recover  data  from 
an  LC2IEDM  database,  it  would  translate  both  NOP  and  MOPS  to  damaged. 

E.4.2  Rules  for  Boolean  Domains 

The  EC2IEDM  has  no  attributes  with  Boolean  domains.  This  does  not  mean  that  Boolean 
JSIMS  attributes  cannot  be  aligned,  just  that  the  alignment  never  consists  of  a  direct 
mapping  of  true/false  values. 

Here  are  strategies  for  alignment  assessments  derived  from  a  State-level  assessment  of  a 
Boolean  JSIMS  attribute  ja. 

1 .  Suppose  the  State-level  assessment  determines  that  ja  aligns  to  a  EC2IEDM  attribute 
la  There  are  two  ways  to  represent  the  true/false  value  for  4: 

a)  Partition  the  domain  of  U  into  two  sets  of  values,  one  of  which  denotes  “true”  and 
the  other  “false”. 

Eor  example,  if  4  represents  a  quantity  and  4  is  an  integer  domain,  then  0  might 
correspond  to  false  and  all  positive  values  to  true. 

b)  The  existence  of  a  value  for  4  may  be  sufficient  to  denote  truth.  In  other  words, 
“true”  maps  to  “non-null”  and  “false”  maps  to  “null”. 
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In  both  cases,  if  an  assessor  ean  establish  a  mapping,  the  Value-level  degree  of 
alignment  is  100%.  If  he  eannot  establish  a  mapping,  the  Value-level  degree  of 
alignment  is  0%. 

2.  Sometimes  ja  is  modeled  in  the  LC2IEDM  by  the  presenee  or  absenee  of  entities  and 
relationships.  If  so,  the  assessor  does  not  have  to  perform  a  Value-level  alignment  as¬ 
sessment.  Instead,  assess  the  State-level  alignment.  If  the  presenee  or  absenee  ean  be 
modeled  unambiguously,  the  degree  of  State-level  alignment  is  100%.  Otherwise,  the 
degree  of  State-level  alignment  is  0%. 

In  all  eases,  the  degree  of  alignment  for  a  boolean-valued  JSIMS  attribute  is  either  0%  or 

100%. 

E.4.3  Rules  for  Integer  Domains 

Integer  JSIMS  quantities  are  represented  using  4  bytes,  whieh  means  they  ean  range  from 
-2^'  to  2^' -I.  If  an  integer-typed  JSIMS  attribute  ja  maps  to  an  integer-typed 
LC2IEDM  attribute  (i.e.,  one  whose  representation  is  NUMBER(n)),  then  the  degree  of 
alignment  depends  on  whether  n  deeimal  digits  ean  store  all  the  values  ja  can  hold.  The 
rule  is  that  the  Value-level  degree  of  alignment  is  the  pereent  of  possible  JSIMS  values 
that  ean  be  stored  by  the  EC2IEDM  attribute. 

Eor  some  EC2IEDM  attribute  whose  domain  is  NUMBER(n),  «<10  (10  being  the  num¬ 
ber  of  digits  in  2^'  -1)  does  not  automatieally  imply  the  domain  of  ja  aligns  less  than 
100%.  The  elass  org.land.equip_group  has  an  attribute  number_of_platforms  that  stores  the  num¬ 
ber  of  platforms  in  the  equipment  group.  In  EC2IEDM,  an  OBJECT-ITEM  may  have  an  as- 
soeiated  HOLDING;  the  HOLDING-OPERATIONAL-QUANTITY  attribute  reeords  the  number  of 
items  held.  The  type  of  number_of_platforms  is  long.  The  domain  of  HOLDING-OPERATIONAL- 
QUANTITY  is  NUMBER(9).  EC2IEDM  therefore  ean’t  model  any  JSIMS  simulation  where  an 
equipment  group  has  over  a  billion  platforms.  But  when  will  sueh  a  simulation  oeeur?  In 
praetiee,  then,  the  degree  of  Value-level  alignment  is  100%.  The  assessors  are  expeeted  to 
use  eommon  sense  to  determine  what  range  is  realistie.  And  they  should  be  sure  to  reeord 
their  rationale  in  their  Value-level  assessment! 

As  with  Boolean-typed  attributes,  there  are  situations  where  alignment  of  an  integer  value 
is  possible  even  though  the  EC2IEDM  doesn’t  have  a  matehing  attribute,  beeause  the  in¬ 
teger  is  represented  by  the  existenee  of  entities  and  relationships.  The  previous  paragraph 
(whieh  eontains  a  little  white  lie)  is  an  example.  The  way  to  obtain  the  number  of  plat¬ 
forms  would  be  to  model  an  equipment  group  as  an  ORGANISATION,  to  model  platforms  as 
MATERIEL,  and  to  eount  the  number  of  ORGANISATION-MATERIEL-ASSOCIATION  entities 
(where  the  value  of  ORGANISATION-MATERIEL-ASSOCIATION-CATEGORY-CODE  is  CTRL) 
where  the  ORGANISATION-MATERIEL-ORGANISATION-SUBJECT-ORGANISATION-ID  attribute  is 
that  of  the  equipment  group  in  question. 
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E.4.4  Rules  for  String  Domains 

A  JSIMS  string  is  encoded  as  a  4-byte  integer  n  giving  the  length  of  the  string,  followed 
by  n  bytes  containing  the  string  (padded  to  4-byte  chunks).  The  maximum  length  of  a 
string  in  JSIMS  is  therefore  2^'  - 1 . 

LC2IEDM  uses  VARCHAR(n)  to  represent  strings.  There  are  at  least  two  cases  for  calculat¬ 
ing  Value-level  degree  of  alignment.  Both  depend  upon  knowledge  of  the  string-typed 
JSIMS  attribute y'a  whose  alignment  is  being  assessed. 

1.  If  7a  is  constrained  to  have  a  predefined  length  /,  then  it  aligns  100%  if  the  corre¬ 
sponding  LC2IEDM  attribute’s  domain  is  VARCHAR(n),  n>  I .  Otherwise,  its  Value- 
level  degree  of  alignment  is  0%. 

As  an  example,  JSIMS  associates  a  name  with  each  organization  in  the  org_name  at¬ 
tribute  of  the  org  class.  The  corresponding  EC2IEDM  attribute  is  UNIT-FORMAL-NAME, 
the  representation  of  which  is  VARCHAR(25).  Now  suppose  (this  is  purely  hypothetical) 
that  a  particular  simulation  adopts  the  convention  that  all  unit  names  are  to  be  exactly 
30  characters  long.  There  is  no  way  to  model  even  one  JSIMS  unit  name  in  the 
EC2IEDM,  so  the  Value-level  degree  of  alignment  is  0%. 

2.  If 7a  is  not  constrained  to  have  a  predefined  length,  then  it  is  necessary  to  know  if  the 
length  of  7a  will  ever  exceed  n.  If  not,  then  the  Value-level  degree  of  alignment  is 
100%. 

If  it  is  possible  that  length(7^  )>  n  ,  then  there  are  at  least  two  ways  to  assess  the  de¬ 
gree  of  alignment: 

a)  If  probability  p  that  length(7^ )  >  n  is  known  (by  frequency  analysis,  say),  then 
the  Value-level  degree  of  alignment  is  then  I-  p  . 

b)  Otherwise,  we  assume  that  all  lengths  are  equally  likely.  The  assessor  should 
identify  a  probable  maximum  length  m  (i.e.,7a  will  not  be  longer  than  m  in  prac¬ 
tice).  The  Value-level  degree  of  alignment  is  n/m. 

Note  that  assuming  that  all  lengths  are  equally  likely  is  not  the  same  as  assuming 
that  all  values  are  equally  likely.  The  latter  would  yield  a  much  lower  degree  of 
alignment:  256”*  "  (assuming  256  possible  characters).  If  the  assessor  has  reason 
to  believe  that  all  values  are  equally  likely,  he  should  assess  alignment  based  on 
that  assumption. 

There  are  some  other  cases  worth  mentioning. 

3.  Strings  don’t  always  map  to  strings.  JSIMS  models  object  identifiers  as  strings.  The 
EC2IEDM  models  identifiers  using  one  of  three  domains:  NUMBER(12),  NUMBER(15), 
and  NUMBER(18).  Since  a  simulation  is  unlikely  to  have  10^^  distinct  objects,  to  say 
nothing  of  10^* ,  the  degree  of  Value-level  alignment  for  identifiers  is  100%.  To  im¬ 
plement  alignment  would  require  defining  a  function  that  transforms  identifiers  be¬ 
tween  the  two  models. 
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4.  JSIMS  contains  a  few  “description”  attributes  (e.g.,  in  natsim. missions)  whose  purpose 
is  to  provide  for  free  text  description.  LC2IEDM  has  a  few  such  attributes;  their  do¬ 
main  is  either  VARCHAR(255)  or  VARCHAR(2000).  255  characters  isn’t  long  enough  for 
much  free  text,  and  even  2000  characters  is  stingy.  But  using  the  formulas  above  will 
result  in  unreasonably  small  degrees  of  alignment.  If  the  assessor  assumes  a  descrip¬ 
tion  might  have  at  most  100,000  characters,  its  degree  of  alignment  would  be 
1- (100000-2000)/!  00000  =  2%  ,  which  seems  low.  It  is  probably  best  to  use  an  ar¬ 
bitrary  value  such  as  75%  for  the  degree  of  alignment. 

E.4.5  Rules  for  Double  Domains 

If  the  type  of  JSIMS  attribute  ja  is  double,  then  the  general  approach  to  alignment  in¬ 
volves  determining  whether  the  corresponding  LC2IEDM  attribute(s)  can  model  both  the 
range  and  precision  of  a  real  number  represented  as  a  64-bit  floating-point  quantity.  The 
assessor  should  constrain  this  approach  based  on  the  actual  values  that  might  be  used  in 
JSIMS,  rather  than  the  complete  range  of  floating-point  numbers  that  can  be  represented 
in  64  bits. 

In  both  JSIMS  and  the  EC2IEDM,  real  numbers  are  used  to  model  physical  characteris¬ 
tics:  coordinates,  speed,  capacity,  etc.  The  purpose  of  an  attribute  constrains  its  range. 
Eatitude  will  always  be  in  the  range  ±90.  Eongitude  will  always  be  in  the  range  ±180. 
Speeds  will  never  exceed  lO"^  (or  possibly  10^  for  a  satellite).  Dimensions  of  cargo  con¬ 
tainers  can  be  measured  in  tens  (possibly  hundreds)  of  meters. 

Unfortunately,  JSIMS  does  not  state  the  required  number  of  significant  digits.  It  does 
state  units,  and  perhaps  the  assumption  is  that  numbers  are  expected  to  be  resolved  to 
those  units. 

The  EC2IEDM  uses  fixed-point  domains.  These  domains  specify  both  precision  (number 
of  significant  digits)  and  scale  (number  of  digits  after  the  decimal  point). 

The  following  rules  apply.  Suppose  the  State-level  assessment  of  ja  aligns  it  to  exactly 
one  EC2IEDM  attribute  whose  representation  is  NUMBER(m,n).  Derive,  based  on  the  pur¬ 
pose  of  ja,  its  minimum  and  maximum  possible  values,  and  the  number  of  significant  dig¬ 
its  it  must  contain  such  that  ja  can  represent  a  value  to  within  ±1  unit  of  measure.^  Then: 

1.  The  Value-level  degree  of  alignment  is  100%  if  NUMBER(m,n)  can  represent  the  com¬ 
plete  range  with  the  necessary  precision. 

2.  If  NUMBER(m,n)  can  represent  the  complete  range  but  not  the  necessary  precision,  then 
the  Value-level  degree  of  alignment  is  l-fyni,  where  s  is  the  number  of  significant 
digits  that  NUMBER(m,n)  can’t  represent.^ 


^  Sometimes  this  doesn’t  work.  For  instance,  JSIMS  measures  latitude  in  degrees.  Sixty  nautical  miles 
isn’t  sufficiently  precise  resolution.  In  cases  like  this,  the  assessor  has  to  get  the  required  precision 
from  JSIMS. 

^  LC2IEDM  uses  base  10  whereas  JSIMS  uses  base  2;  this  makes  calculating  ^  tricky,  because  m  signifi¬ 
cant  digits  in  base  10  doesn’t  usually  equate  to  an  integral  number  of  significant  digits  in  base  2.  This 
may  result  in  small  rounding  errors,  but  we  deemed  them  insignificant. 
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3.  If  NUMBER(m,n)  can  represent  the  neeessary  preeision  but  not  the  eomplete  range,  then 
the  Value-level  degree  of  alignment  is  the  pereentage  of  the  range  that  is  eovered. 

4.  If  NUMBER(m,n)  ean  represent  neither  the  neeessary  preeision  nor  the  eomplete  range, 
then  the  Value-level  degree  of  alignment  is  the  produet  of  items  2  and  3. 


E-8 


Appendix  F.  WARSIM-JCDB  ALIGNMENT 

ASSESSMENT^ 


Table  of  Contents 


F.  1  Introduction . F-7 

F.  1 . 1  Problem  Statement . F-7 

F.  1 .2  Overview  of  the  Joint  Common  Database . F-8 

F.1.3  Overview  of  Appendix . F-9 

F.2  Analysis  Approach . F-9 

F.2. 1  Analysis  Proeess . F-9 

F.2.2  Seoring . F-11 

F.2. 3  Non-Issues . F-11 

F.3  Summary  of  Alignment  Analysis  Results . F- 1 3 

F.3 . 1  Mapping  WARSIM  into  the  JCDB . F- 1 3 

F.3. 2  Mapping  JCDB  into  WARSIM . F-15 

F.4  Conclusions . F- 1 7 

F.4.1  Coneepts  modeled  in  WARSIM  missing  from  the  JCDB . F-17 

F.4.2  Coneepts  modeled  in  the  JCDB  missing  from  WARSIM . F-18 

F.4. 3  Differenees  in  the  ways  details  are  modeled . F-18 

F.5  Recommendations . F- 1 9 

F.6  Alignment  detail  tables . F-20 


An  earlier  version  of  this  appendix  was  published  separately  as  [MHLW  2002]. 


F-1 


List  of  Figures 


Figure  F-1.  Fligh-level  depiction  of  battlefield  objects  in  the  JDM . F-8 

Figure  F-2.  Example  Unit  area  alignment  mapping  and  assessments . F-10 

Figure  F-3.  Unit  area  alignment  assessment  results . F-15 

Figure  F-4.  Equipment  area  alignment  assessment  results . F-15 

Figure  F-5.  Organization  area  alignment  assessment  results . F-1 7 


F-3 


List  of  Tables 


Table  F-1.  Summary  of  Assessment  Results  for  Mapping  WARSIM  Object  Classes  into  JCDB 


Entities . F-13 

Table  F-2.  Summary  of  TCDM  Assessment . F-14 

Table  F-3.  JCDB  Primary  Entities  mapped  to  the  WARSIM  Object  Model . F-16 

Table  F-4.  Mapping  WARSIM  unit  area  to  JCDB . F-23 

Table  F-5.  Mapping  TCDM  Features  into  the  JCDB . F-32 

Table  F-6.  Mapping  org.land.equip  group  to  JCDB . F-40 

Table  F-7.  Mapping  org.land.supply  cache  to  JCDB . F-47 

Table  F-8.  Mapping  platform. shelter. equipment  to  JCDB . F-52 

Table  F-9.  Mapping  minefield. land  to  JCDB . F-56 

Table  F-10.  Mapping  abstractland.equip  type  to  JCDB . F-57 

Table  F-1 1.  Mapping  abstract.land.personnel  type  to  JCDB . F-59 

Table  F-12.  Mapping  abstract. land.rotary  wing  type  to  JCDB . F-60 

Table  F-13.  Mapping  ORG  to  WARSIM . F-62 

Table  F-14.  Mapping  MAT  to  WARSIM . F-65 

Table  F-1 5.  Mapping  ENEMY  MAT  to  WARSIM . F-68 

Table  F-16.  Mapping  MAT  ITEM  to  WARSIM . F-76 

Table  F-1 7.  Mapping  CONSUMABEES  to  WARSIM . F-80 

Table  F-1 8.  Mapping  EQUIP  TYPE  to  WARSIM . F-83 

Table  F-1 9.  Mapping  SENSOR  TYPE  to  WARSIM . F-85 


F-5 


F.l  Introduction 


In  the  main  body  of  this  report,  the  degree  of  alignment  between  NATO’s  Land  C2  In¬ 
formation  Exehange  Data  Model  (LC2IEDM)  [NATO  2000]  and  the  Warfighter’s  Simu¬ 
lation  (WARSIM)  “objeet  model”  is  deseribed,  along  with  a  methodology  for  doing  the 
analysis.  This  appendix  extends  that  analysis  to  present  assessment  results  of  an  analysis 
of  alignment  between  the  WARSIM  objeet  model  and  the  Joint  Common  Database 
(JCDB)  Data  Model  (JDM). 

While  the  EC2IEDM  is  a  well-tested  speeifieation  for  data  exchange  within  coalition  op¬ 
erations,  for  historical  reasons  the  US  Army  has  not  adopted  it  for  use  in  its  national  C2 
systems.  That  role  corresponds  to  the  JCDB,  a  physical  database  developed  with  consid¬ 
erable  effort,  that  is  currently  used  in  every  major  Army  Tactical  Command  and  Control 
System  in  its  Army  Battle  Command  System  (ABCS).  In  addition,  the  WARSIM  pro¬ 
gram,  the  largest  training  simulation  in  the  Army,  has  a  requirement  to  interface  to  the 
JCDB  of  the  ABCS.  This  requirement  has  not  yet  been  met,  and  the  alignment  analysis 
described  here  is  considered  an  important  step  in  achieving  the  necessary  interoperability. 

Thus,  while  we  judged  the  LC2IEDM  to  be  the  best  reference  model  for  Army  C4I  data, 
we  realized  that  WARSIM’s  alignment  with  the  JCDB  is  also  an  important  issue.  The 
JCDB  alignment  results  are  an  important  part  of  the  overall  study  and  show  a  more  short¬ 
term  alignment  picture.  The  alignment  results  cited  here  show  the  actual  alignment  be¬ 
tween  the  WARSIM  models  and  a  C4I  data  model  and  physical  database.^ 

F.1.1  Problem  Statement 

The  U.S.  Army  has  several  reasons  for  wanting  to  connect  models  and  simulations  to  op¬ 
erational  command  and  control  (C2)  systems,  including; 

•  Training  soldiers  in  using  the  C2  systems  without  needing  to  have  all  other  ele¬ 
ments  of  a  force  present. 

•  Testing  C2  equipment  without  needing  to  have  all  other  systems  present. 

•  Simulating  alternative  proposed  courses  of  action. 

•  Rehearsing  planned  missions. 

In  spite  of  these  and  other  requirements  to  make  modeling  and  simulation  (M&S)  sys¬ 
tems  and  C2  systems  interoperate,  making  them  do  so  is  still  a  very  difficult  task.  One  of 
the  main  sources  of  this  difficulty  is  the  lack  of  alignment  among  the  object/data  models 
used  by  these  two  communities. 

There  is  a  trend  in  the  Army,  however,  that  will,  in  the  not-to-distant  future  make  it  much 
easier  to  make  these  data  models  align:  The  Army  is  standardizing  its  data  models  in  each 
of  these  communities  for  future  systems.  Already,  the  Army  C4I  community  has  adopted 
the  JCDB  as  a  common  database  for  all  Army  tactical  C4I  systems,  and  the  SIMCI  OIPT 
is  developing  a  C4I-M&S  Reference  Object  Model  (C-ROM)  for  M&S  development  that 
incorporates  all  the  JCDB  data  requirements.  Hence,  an  assessment  of  the  current  JCDB 


^  Based  on  Version  5.0  of  the  JCDB  and  Version  6.0  of  the  JSIMS  FOM. 
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data  alignment  with  WARSIM  provides  one  indieation  of  how  mueh  needs  to  be  done  to 
ereate  a  eommon  referenee  model  that  supports  both  M&S  and  C4I  system  data  require¬ 
ments.  The  immediate  objeetive  of  the  analysis  reported  in  this  appendix  is  to  show  the 
degree  to  whieh  the  speeific  JCDB  data  model  aligns  with  a  eurrent  Army  Simulation, 
and  where  they  do  not  align,  to  provide  some  of  the  details  on  what  needs  to  ehange.  In 
the  short  term,  this  should  assist  WARSIM  in  developing  their  interfaee  to  the  JCDB.  The 
longer  term  objeetive  is  to  provide  input  to  developing  a  eommon  C4I-M&S  referenee 
model,  whose  use  eould  ensure  data  interoperability  and  promote  effeetive  and  effieient 
integration  of  Army  C4I  and  M&S  systems. 

F.1.2  Overview  of  the  Joint  Common  Database® 

The  version  of  the  JCDB  used  in  this  assessment  eorresponds  to  the  release  of  Oetober 
2001  by  PEO-C3S  at  Ft.  Monmouth.  It  eontains  572  entities,  379  of  whieh  are  independ¬ 
ent.  Out  of  the  379  independent  entities  329  represent  externalized  eodes  whieh  permit 
reuse  within  the  model,  and  faeilitate  maintenanee  and  update.  The  JCDB  has  the  5  bat¬ 
tlefield  instanee  entities  FACILITY,  FEATURE,  MATERIEL,  ORGANIZATION  and 
PERSON,  as  well  as  its  own  version  for  their  respeetive  type  entities,  namely,  FACIL- 
ITY-TYPE-SYMBOL,  FEATURE-TYPE-SYMBOL,  MATERIEL-ITEM,  ORGANIZA¬ 
TION-TYPE  and  PERSON-TYPE,  as  shown  in  Figure  F-1.  Information 
about  enemy  objeets  is  separately  maintained  in  ENEMY-ORGANIZATION,  ENEMY- 
PERSON,  and  ENEMY_MATERIAL.  It  also  eontains  a  rieh  superstrueture  to  handle  data 
related  to  PLANS,  ACTION,  TASK,  MISSION,  and  DOCUMENT  entities  among  others. 


FACILITY-TYPE-SYMBOL 


FEATURE-TYPE-SYMBOL 


MATERIEL-ITEM 


ORGANIZATION-TYPE 


PERSON-TYPE 


Figure  F-1.  High-level  depiction  of  battlefield  objects  in  the  JDM 


The  model  and  physieal  sehema  for  the  JCDB  were  developed  by  the  Army's  PEO-C3S 
(now  the  PEO-C3T)  at  Ft.  Monmouth  to  support  the  C2  requirements  of  the  Army  Battle 
Command  System  (ABCS).  It  is  an  operational  implementation  of  the  C2CDM  and  has 
interfaees  to  the  major  Army  C4ISR  information  systems.  As  with  the  model  developed 
by  the  International  Army  Taotieal  Command  and  Control  Information  System  (ATCCIS) 
[Tolk  1999]  for  eoalition  operations,  the  JCDB  is  meant  to  serve  as  the  eommon  speeifi- 
eation  for  information  exehange  among  all  the  eomponents  of  the  ABCS.  Substantial  por¬ 
tions  of  the  JCDB  have  undergone  standardization  under  the  DoD  8320  proeess,  and  data 
segments  have  been  ereated  by  the  Common  Operating  Environment  (COE)  ShaDE  to 
provide  interoperability  with  other  information  systems.  The  model  is  maintained  under 
striet  eonfiguration  eontrol  by  PEO-C3T. 


^  An  overview  of  the  WARSIM  object  model  can  be  found  in  Section  2  of  the  main  body  of  this  report. 
[HHHLMMPW  2002]. 


F-8 


The  current  release  of  the  JCDB  is  version  5.0.  The  major  changes  with  respect  to  the 
previous  deployed  version  are  in  the  area  of  valid  domain  codes  needed  to  support  newly 
identified  ABCS  information  requirements.  A  more  complete  description  of  the  JCDB  can 
be  found  in  [HB  1999,  THGS  1998].^ 

F.1.3  Overview  of  Appendix 

Section  F-2  describes  the  analysis  approach  taken  to  arrive  at  the  results  summarized  in 
Section  F-3.  Section  F-4  then  provides  our  conclusions  about  those  results,  and  Section 
F-5  provides  our  recommendations  on  the  way  forward.  This  is  followed  by  two  sets  of 
tables  that  provide  the  details  on  the  assessments  of  alignment.  Tables  F-4  to  F-12  pro¬ 
vide  details  on  mapping  WARSIM  to  JCDB,  and  Tables  F-13  to  F-19  provide  details  on 
mapping  JCDB  to  WARSIM. 

F.2  Analysis  Approach 

F.2.1  Analysis  Process 

The  basic  approach  to  the  analysis  is  described  fully  in  the  main  body  of  this  report,  as 
well  as  in  [HLMP  2002a,  WHLH  2002,  WHLH  2001a,  WHLH  2001b].  Some  shortcuts  in 
that  methodology  were  made  in  this  work  due  to  time  and  resource  constraints,  and  are 
described  in  this  section.  The  analysis  of  the  degree  of  alignment  between  WARSIM  and 
the  JCDB  was  conducted  in  two  phases.  In  phase  I,  the  ability  to  move  WARSIM  data 
into  the  JCDB  was  analyzed.  The  focus  in  this  phase  was  on  instance  data.  That  is,  given 
an  instance  of  a  class  in  WARSIM,  is  it  possible  to  represent  that  instance  faithfully  in  the 
JCDB.  In  phase  2,  the  opposite  direction  was  analyzed. 

The  first  step  phase  1  is  to  identify  the  classes  in  WARSIM  that  can  represent  instances. 
The  second  step  is  to  identify  all  the  attributes  of  such  instances.  Such  attributes  may 
come  from  the  classes  that  have  instances,  superclasses,  classes  that  are  related  through 
relationships,  or  classes  that  represent  complex  data  types  of  these  attributes. 

Once  all  the  attributes  of  possible  instances  are  known,  the  task  is  to  identify  entities  in 
JCDB  that  represent  the  same  kind  of  instances,  and  determine  if  the  attributes  of  WAR¬ 
SIM  can  be  represented  in  the  corresponding  JCDB  entities.  It  is  not  expected  that  a  sin¬ 
gle  WARSIM  class  will  map  into  a  single  JCDB  entity,  because,  just  as  all  the  attributes 
of  a  WARSIM-modeled  instance  are  not  found  in  a  single  class,  instance  data  for  a 
JCDB-modeled  instance  are  not  found  in  a  single  JCDB  entity,  as  illustrated  in  Figure 
F-2.  This  figure  shows  how  the  WARSIM  attribute  org.land.unit.task  maps  into  the  JCDB 
attribute  ORGANIZATION-OPERATIONAL-STATUS-current-activity-code  and  re¬ 
quired  associated  attributes  in  the  ORGANIZATION  and  PERCEPTION  entities.  Also 
shown  is  the  WARSIM  attribute  org.land.unit.frequency,  with  its  mapping  into  the  JCDB 
attribute  NETWORK-EINK  operating  frequency  rate  and  required  associated  attributes  in 
the  NETWORK,  ORGANIZATION-NETWORK,  and  ORGANIZATION  entities. 


’  Additional  information  regarding  the  JCDB  ean  be  found  on  the  JCDB  website: 
https://peoe3s.monmouth.army.mil/peoe3sjedb.nsF 
This  requires  registration,  whieh  is  possible  at: 
http://www.monmouth.army.mil/newpages/vCpeoe3s.html 
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WARSIM 


JCDB 


ORGANIZATION 


org.land.unit 


task :  String 
frequency :  Dout^ 


ORGANIZATION  identifier 

ORGJNPUTJD _ 

ORGANIZATION  unit  identification  code 
ORGANIZATION  name 
ORGANIZATION  formal  abbreviated  name 
ORGANIZATION-TYPE  identifier(FK) 
ORGANIZATION-TYPE  IN  PUT  identifier  (FK)  I 


ORGANIZATION-OPERATIONAL-STATUS 


/6rG  input  id  (FK) 

ORGANIZATION  identifier  (FK) 
organization-operation  AL-STATUSid  entifier 

ORGANIZATION-OPERATIONAL-STATUS  current  activitycode 
PERCEPTION  identifier  (FK) 

PERCEPTION  input  identifier  (FK) 

k: 

_ J 

• 

1 

1 

1 

1 

PERCEPTION  ' 

/Perception  identifier 

PERCEPTION  incut  identifier 

\ 

REPORTING-ORGANIZATION  identifier 
REPORTING-ORGANIZATION  input  identifier 
PERCEPTION  start  time 

PERCEPTION  end  time 

N 

Figure  F-2.  Example  Unit  area  alignment  mapping  and  assessments 

Compare  this  diagram  to  Figure  21  in  Section  6.1.2  in  the  body  of  the  report.  The  map¬ 
pings  to  the  JCDB  are  quite  different  from  those  to  the  LC21EDM.  The  JCDB  models 
frequency  perfectly,  but  it  models  task  imperfectly.  In  the  LC21EDM,  the  current  task  of 
an  organization  is  identified  by  an  association  between  the  Organization  and  an  Action- 
Task.  In  the  JCDB,  this  identification  is  made  in  an  attribute  of  ORGANIZATION. 

Eor  phase  2,  analogous  considerations  apply  to  assessing  the  possibility  of  moving  ele¬ 
ments  from  the  JCDB  to  WARSIM.  The  relevant  attributes  of  instances  of  JCDB  entities 
include  attributes  of  subtypes,  associations,  and  entities  related  by  a  parent-child  relation¬ 
ship.  Eor  example,  the  attributes  of  an  ENEMY  ORGANIZATION  come  from  the  follow¬ 
ing  entities: 

•  ENEMY-ORGANIZATION 

•  ENEMY-ORGANIZATION-OPERATIONAE-STATUS 

•  ENEMY-ORGANIZATION-POINT 

•  ENEMY-TRACK-HISTORY 

•  CANDIDATE-TARGET 

•  MATERIEE-ITEM-ENEMY-ORGANIZATION-HOLDING 

•  PERSON-TYPE-ENEMY-ORGANIZATION-HOLDING 

•  ORGANIZATION-TYPE 
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Such  a  collection  of  classes  with  a  foeal  elass  (e.g.,  ENEMY-ORGANIZATION)  eorre- 
sponds  to  a  eoneept  at  the  eoneeptual  level  of  analysis  defined  in  the  eompanion  paper 
[HEMP  2002b]  and  elsewhere  [HEMP  2002a,  WHEH  2002,  WHEH  2001a]. 

F.2.2  Scoring 

The  assessment  is  aimed  at  produeing  a  numerie  value  that  represents  the  degree  of 
alignment  at  eaeh  of  several  levels  in  the  data  model.  At  the  lowest  level,  some  of  the 
numbers  are  assigned  on  a  subjeetive  basis  but  with  the  intent  to  refleet  the  assessor’s 
opinion  of  how  well  the  JCDB  data  elements  ean  eapture  the  semanties  of  the  WARSIM 
data  elements,  or  viee  versa.  Due  to  resouree  eonstraints,  it  was  not  possible  to  ealeulate 
exhaustively  the  degree  of  alignment  for  all  oases.  The  values  assigned  at  the  lower  level 
are  then  averaged  to  arrive  at  an  assessment  of  eaeh  of  the  suooeeding  higher  levels  of  the 
assessment. 

One  group  of  WARSIM  attributes  whioh  were  not  inoluded  in  these  assessments  are  those 
related  speoifioally  to  the  management  of  models  and  simulations.  These  attributes 
olearly  have  no  oounterparts  in  the  JCDB,  but  they  are  published  by  WARSIM  for  the 
purpose  of  ooordination  among  models  and  simulations  that  may  need  to  be  working  in 
the  same  federation,  or  even  in  a  different  federation. 

In  some  eases,  attributes  have  been  assessed  to  align  at  100%  even  though  there  is  no 
eounterpart  attribute.  This  is  usually  in  the  ease  where  a  foreign  key  in  one  model  is  rep¬ 
resented  by  an  aspeet  of  the  strueture  of  the  other  model  that  allows  a  representation  of 
the  same  linkage  through  some  other  means.  Eor  example,  to  indieate  how  many  people 
of  eaeh  oeeupational  speeialty  are  authorized  for  any  unit,  the  WARSIM  objeet  model 
provides  a  eomplex  attribute  AUTHORIZED_PERSONNEE_  EEVEES  of  the  elass 
ORG.E AND. UNIT  that  eontains  two  sub-attributes,  AUTHORIZED_  AMOUNT  and 
MOS  (Military  Oeeupational  Speeialty).  In  the  JCDB,  however,  PERSONNEE-TYPE  is 
a  separate  entity,  and  there  is  an  assoeiation  between  it  and  ORGANIZATION  ealled 
PERSON-TYPE-ORGANIZATION-HOEDING  that  has  an  attribute  AUTHORIZED- 
QUANTITY.  This  JCDB  entity  has  as  foreign  keys,  the  key  attributes  of  ORGANIZA¬ 
TION  and  PERSONNEE-TYPE,  as  well  as  an  additional  key  to  permit  multiple  instanees 
of  sueh  holdings. 

This  example  highlights  the  faet  that  whereas  the  WARSIM  objeet  model  uses  strueture 
to  represent  relationships,  the  JCDB  uses  foreign  keys.  The  attribute  AUTHORIZED_ 
PERSONNEE_EEVEES  is  a  list  of  values,  one  for  eaeh  equipment  group  in  a  unit.  The 
assoeiation  with  a  speeifie  unit  is  established  by  position  on  the  list.  That  is,  there  is  also 
a  list  of  equipment  groups,  and  the  i-th  equipment  group  has  the  i-th  authorized  personnel 
level.  This  way  of  representing  sueh  a  relationship  is  just  as  explieit  and  unambiguous  as 
the  way  the  JCDB  uses  foreign  keys,  but  in  moving  data  from  the  JCDB  to  the  WARSIM 
objeet  model,  the  use  of  foreign  keys  in  the  JCDB  to  link  entities  is  replaeed  by  the  strue¬ 
ture  of  the  WARSIM  eomplex  attributes. 

F.2.3  Non-Issues 

Before  deseribing  problems  with  the  alignment  of  the  two  subjeet  data  models,  it  may  be 
useful  to  the  reader  to  point  out  some  areas  of  superfieial  misalignment  that  are  not  real 
problems  given  the  foeus  here  on  model  support  for  exehange  of  instanee  data.  They  fall 
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into  three  categories,  mapping  high-level  classes/entities,  and  mapping  low-level  classes, 
and  category  code  entities. 

High-level  classes  or  entities  provide  a  structuring  mechanism  that  permits  instance 
classes  to  inherit  attributes.  The  structuring  mechanisms  used  by  JCDB  do  not  match 
those  of  WARSIM  virtually  anywhere,  but  instances  take  on  most  of  the  same  set  of  at¬ 
tributes  in  many  cases.  Since  the  main  concern  is  moving  instance  data,  the  inability  to 
map  between  the  higher-levels  of  WARSIM  classes  and  JDM  entities  may  be  of  no  con¬ 
cern  in  such  cases. 

High-level  classes  generally,  serve  organizing  purposes  that  go  beyond  the  exchange  of 
instance  data.  But,  some  high-level  entities  (i.e.,  an  IDEFIX  incomplete  categorization) 
can  provide  a  flexibility  to  models  by  supporting  an  open-ended  set  of  instance  subtypes 
through  an  attribute  such  as  a  type  name  (as  expressed  in  IDEFIX  incomplete  subtype 
relations  -  see  Appendix  A).  This  can  enable  such  models  to  distinguish  more  subtypes  of 
instances  than  would  be  possible  without  those  entities,  even  though  they  both  equally 
support  all  the  other  attributes  of  such  instances.  However,  such  entities  don’t  seem  in¬ 
volved  in  the  WARSIM -JCDB  alignment  assessment.  High  level  entities  also  support  the 
normalization  of  data  models  in  ER  modeling  and  efficient  structuring  of  inheritance  for 
object  models.  But,  these  were  not  concerns  in  this  alignment  assessment  with  its  focus 
on  instance  data. 

WARSIM  makes  use  of  “low-level”  elements  as  complex  data  types  for  attributes.  For 
example,  the  data  type  of  many  location  attributes  is  COORDINATE_3D_C,  a  complex 
data  type  with  three  attributes,  elevation,  latitude,  and  longitude.  Due  to  their  structure, 
such  elements  are  treated  as  distinct  for  alignment  assessment  purposes.  The  JCDB  does 
not  have  such  an  abstract  entity,  but  every  entity  that  needs  a  3-dimensional  location  has 
those  same  attributes.  Hence,  although  the  COORDINATE_3D_C  class  has  no  direct 
counterpart  in  the  JCDB,  at  the  instance  level  it  makes  no  difference.  This  is  one  of  the 
reasons  the  context  of  an  instance  is  important  in  mapping  WARSIM  data  into  the  JCDB. 
For  example,  in  WARSIM,  movement  data  is  maintained  in  the  complex  data  type 
MOVE_SEGMENT_C  for  all  things  that  move.  Several  of  the  attributes  of  this  type  are 
themselves  modeled  as  complex  data  types,  and  several  of  these  store  positions  in  the 
three  coordinate  structure  described  above. 

However,  when  it  comes  to  mapping  these  WARSIM  complex  data  types  into  the  JCDB, 
the  context  determines  how  the  mapping  should  be  done.  For  example,  in  the  JCDB  the 
position  of  a  unit  needs  to  be  mapped  into  FRIENDFY-ORGANIZATION-POINT  or 
ENEMY-ORGANIZATION-POINT  depending  on  whose  unit  it  is,  but  the  position  of  a 
platform  needs  to  be  mapped  into  MATERIAE-POINT  or  ENEMY-MATERIEF-POINT. 

Category  code  entities  are  used  in  the  JCDB  to  “externalize”  the  metadata  about  the  ac¬ 
ceptable  values  for  category  code  attributes,  which  are  the  discriminators  used  to  distin¬ 
guish  subclasses  in  the  JDM.  Another  model  may  be  well  aligned  with  the  JCDB  without 
having  separate  classes  or  entities  for  these  codes,  provided  it  has  attributes  or  subclasses 
that  support  all  the  values  in  those  codes. 
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F.3  Summary  of  Alignment  Analysis  Results 

This  section  presents  a  summary  of  the  some  of  the  key  results  of  the  analysis.  The  de¬ 
tailed  results  are  presented  in  Tables  F-4  to  F-19  at  the  end  of  this  appendix.  Tables  F-4  to 
F-12  provide  details  on  mapping  WARSIM  to  JCDB,  and  Tables  F-13  to  F-19  provide 
details  on  mapping  JCDB  to  WARSIM. 

F.3.1  Mapping  WARSIM  into  the  JCDB 

F.3. 1.1  Entity  Level  Assessments 

Table  F-1  shows  the  results  of  the  assessment  of  the  primary  WARSIM  managed  classes 
from  the  JSIMS  FOM  [JSIMS  2001]  for  which  assessment  results  are  available  for  this 
paper.  The  numbers  in  the  table  should  be  viewed  primarily  as  relative  to  each  other.  For 
example,  the  JCDB  represents  units  (as  organizations)  better  than  it  does  equipment 
groups,  and  supply  caches  are  represented  only  poorly  by  comparison. 

Table  F-1.  Summary  of  Assessment  Results  for  Mapping  WARSIM  Object  Classes 

into  JCDB  Entities 


WARSIM  Class 

Assessment 

ORG 

61 

ORGEAND 

56 

ORGEAND.UNIT 

56 

ORGEAND.EQUIPGROUP 

43 

ORGEAND.SUPPEYCACHE 

23 

ABSTRACT 

18 

ABSTRACT.EAND 

63 

ABSTRACT.EAND.EQUIPMENTTYPE 

48 

ABSTRACT.EAND.PERSONNEETYPE 

58 

ABSTRACT.EAND.ROTARYWINGTYPE 

48 

PEATEORM 

41 

PEATEORM.  SHEETER 

41 

PEATEORM.SHEETER.EQUIPMENT 

42 

MINEEIEED 

42 

MINEEIEED.LAND 

32 

In  all,  a  total  of  26  WARSIM  object  model  classes  were  assessed.  In  addition  to  the  15 
classes  listed  above,  an  additional  11  complex  data  types  were  assessed.  This  does  not 
include  those  complex  data  types  for  which  there  is  only  one  attribute,  such  as  ID_C  or 
MOVE_DATA_C.  Of  these  26  classes,  only  four  are  assessed  at  zero  percent  alignment, 
and  all  four  of  them  are  not  actually  used  by  WARSIM  (being  used  by  other  federates  in 
JSIMS).  These  are  the  movement  types  GREAT  CIRCLE  C,  KEPEERIAN  C,  EOI- 
TER  C,  and  RHUMB  EINE  C. 
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Assessment  results  at  the  “entity”  level  are  also  available  for  the  TCDM  [JSIMS  1999]. 
The  “features”  whieh  are  organized  into  the  environmental  “coverage”  areas  cited  above 
in  Section  F.2.3,  correspond  to  entities  in  a  relational  model.  This  study  examined  TCDM 
features  only  at  the  entity  level  to  determine  if  the  JCDB  has  explicit  representations  for 
these  features.  More  detail  on  the  TCDM  alignment  can  be  found  in  Table  F-5. 

The  features  of  the  TCDM  map  primarily  into  the  FEATURE  and  EACIEITY  entities  in 
the  JDM.  This  study  examined  all  167  TCDM  features  that  have  attributes.  About  half  of 
these  map  into  standard  representations  in  the  JCDB.  The  details  of  the  TCDM  alignment 
assessment  are  summarized  in  Table  E-2  by  feature  coverage  area.  The  last  column  of  this 
table,  shows  the  percentage  of  TCDM  classes  in  a  given  coverage  area  that  have  a  stan¬ 
dard  representation  in  the  JCDB. 

The  JCDB  provides  facility-specific  attributes  for  only  three  types  of  facilities,  airport, 
seaport,  and  bridge.  There  are  many  other  types  of  facilities  identified  by  enumerated 
codes,  but  the  attributes  of  these  are  just  the  generic  attributes  of  the  entity  EACIEITY. 
The  JCDB  EEATURE  hierarchy  has  a  similar  structure  with  about  10  explicit  types  with 
further  subtypes  distinguished  by  codes.  An  assessment  of  alignment  of  individual  attrib¬ 
utes  of  TCDM  “features”  was  not  performed,  however,  due  to  resource  constraints. 


Table  F-2.  Summary  of  TCDM  Assessment 


TCDM  Coverage 

Number 
of  TCDM 
Classes 

Percent 

TCDM 

Classes 

Mapped 

Subcoverage 

Surface  Areals 

Physiography 

7 

29 

Vegetation 

12 

58 

Urban 

27 

48 

Water 

9 

78 

Point  Culture 

35 

66 

Linear  and  Point  Hydro¬ 
graphy 

15 

47 

Linear  and  Areal  Terrain 
Obstacles 

17 

37 

Maritime  Trafficability 

18 

28 

Linear  and  Point  Trans¬ 
portation 

21 

48 

Administrative  Bounda¬ 
ries 

10 

0 

Battlefield  Elements 

12 

8 

Linear  Connectivity 

3 

0 

Geotile  reference 

1 

0 

F.3.1.2  Attribute  Level  Assessments 

Table  E-4  (in  Section  E.6  below)  shows  the  detailed  assessments  for  the  attributes  that 
contributed  the  entity  level  scores  for  the  Unit  area  shown  above  in  Table  E-1.  These  at- 
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tribute  assessment  results  in  the  Unit  area  are  summarized  below  in  the  ehart  of  Figure 
F-3.  This  ehart  shows,  for  example,  that  18  attributes,  of  the  total  63,  assessed  at  the 
100%  level.  Figure  F-4  shows  the  summary  of  results  for  the  equipment  area. 
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Figure  F-3.  Unit  area  alignment  assessment  results 
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Figure  F-4.  Equipment  area  alignment  assessment  results 
F.3.2  Mapping  JCDB  into  WARSIM 
F.3.2.1  General 

The  assessment  of  the  mapping  of  JCDB  into  WARSIM  was  earried  out  at  the  eoneep- 
tual,  entity,  and  state  levels,  with  aeknowledgement  of  eertain  kinds  of  similarities  and 
differences  at  the  value  level  in  carrying  out  the  state  level  assessments.  That  is,  the  main 
focus  was  on  assessing  the  alignment  of  attributes.  Part  of  this  assessment  included  not¬ 
ing  if  the  values  were  generally  compatible.  The  attribute  assessments  were  then  rolled  up 
to  the  entity  level,  and  the  entity  levels  were  rolled  up  to  the  conceptual  level. 

F.3.2. 2  Entity  Level  Assessments 

Of  the  242  entities  in  the  JCDB  that  are  not  enumeration  lists,  158  seem  to  have  no  useful 
counterpart  in  the  WARSIM  object  model.  The  JCDB  has  19  entities  that  can  be  consid¬ 
ered  to  represent  major  concepts  in  that  they  are  independent,  i.e.,  not  tied  in  any  subor¬ 
dinate  way  to  any  other  entities.  Of  these,  only  eleven  have  any  WARSIM  equivalent  (see 
Table  F-3),  and  even  these  generally  have  very  poor  attribute  alignments.  For  example, 
for  the  most  part  the  WARSIM  object  model  does  not  support  the  concept  of  an  individ¬ 
ual  person,  but  an  EQUIPMENT  GROUP  can  contain  a  person  or  group  of  persons  rep- 
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resented  as  a  platform.  The  PLATFORM  TYPE  of  such  an  equipment  group  is  used  to 
distinguish  a  platform  as  a  person  or  group  of  persons.  The  attributes  such  a  person  would 
have  would  be  mostly  those  that  any  platform  would  have  (ID,  KILL  TYPE, 
MOVE  DATA,  NAME,  SYMBOE  CODE,  and  TYPE)  except  that  PERSON  TYPE 
contributes  one  attribute,  VOEEIME.  Several  specific  attributes  for  persons  that  form  the 
crew  of  a  platform  can  also  be  identified  via  crew  attributes  for  CME,  MOS,  health,  and 
grade.  The  JCDB,  in  contrast,  does  not  model  the  volume  of  a  person,  but  it  does  have 
approximately  175  other  attributes  of  a  person  that  are  distinctly  related  to  personhood. 

Table  F-3.  JCDB  Primary  Entities  mapped  to  the  WARSIM  Object  Model 


Primary  Entities 

Mapped 

to 

WARSIM 

Action 

Address 

X 

Candidate  Target 

Document 

Enemy  Materiei 

X 

Enemy  Organization 

X 

Event 

Faciiity 

X 

Feature 

X 

Fiiter  Definition 

Materiei 

X 

Mateiiei  item 

X 

Organization 

X 

Organization  Type 

X 

Person 

X 

Person  Type 

X 

Plans 

Supported  Target 

Target  Engagement 

F.3.2.3  Attribute  Level  Assessments 

Eigure  E-5  shows  the  distribution  of  attribute  alignment  assessments  for  the  Organization 
area  of  the  JCDB,  which  comprises  ORGANIZATION,  ENEMY-ORGANIZATION  and 
their  related  entities.  The  results  for  MATERIEE  and  ENEMY-MATERIEE,  while  not 
specifically  tabulated,  appear  to  be  comparably  skewed  toward  the  low  end  of  the  scale 
(see  Tables  E-14  through  E-19). 
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Figure  F-5.  Organization  area  alignment  assessment  results 

F.4  Conclusions 

If  the  C4I  and  M&S  communities  want  their  systems  to  interoperate  effectively,  the  data 
models  they  use  need  to  be  better  aligned  than  they  are  today  as  represented  by  the  JCDB 
and  the  WARSIM  models.  This  analysis  demonstrates  the  incompleteness  of  the  mapping 
of  WARSIM  data  into  JCDB  data,  and  vice  versa.  Numerous  concepts  that  are  modeled  in 
one  of  the  models  have  no  counterpart  in  the  other,  and  many  others  are  represented  very 
incompletely.  Of  the  103  attributes  that  contribute  to  the  alignment  of 
ORGLAND.EQUIP  GROUP,  30  received  scores  of  zero,  and  another  11  received  scores 
below  50,  but  only  24  received  scores  of  100.  Similarly,  the  low  alignment  level  of  OR¬ 
GANIZATION  is  because  WARSIM  has  a  very  incomplete  representation  of  command 
and  control  data. 

As  noted  above,  the  FEATURE  and  FACIEITY  aspects  did  not  fare  better.  In  spite  of  the 
existence  of  an  Army  standard  terrain  model,  it  is  largely  unknown  outside  the  modeling 
and  simulation  communities. 

More  telling  than  these  specific  cases,  however,  is  the  order  of  magnitude  difference  in 
the  number  of  attributes  represented  in  the  two  models  (see  Section  F.4. 2  below).  This  is 
clearly  not  a  case  where  a  quick  fix  can  patch  things  together.  From  the  perspective  of  the 
JCDB,  the  WARSIM  object  model  is  missing  90%  of  what  is  needed. 

F.4.1  Concepts  modeled  in  WARSIM  missing  from  the  JCDB 

The  most  obvious  concept  modeled  in  WARSIM  that  is  not  modeled  in  JCDB  is  simula¬ 
tion.  Many  classes  have  attributes  that  are  only  present  to  support  the  simulations  that  use 
the  WARSIM  object  model.  For  example,  there  is  a  Boolean  attribute  of  a  unit  that  indi¬ 
cates  whether  the  unit  is  real  or  simulated. 

The  JCDB  has  no  concept  of  a  security  classification  for  organizations  or  materiel.  Secu¬ 
rity  classification  is  an  attribute  only  of  PFAN  in  the  JCDB.  WARSIM  recognizes  the 
possibility  of  security  markings  on  just  about  anything. 


0%  <50%  >=50%  100% 

■  ORGANIZATION  DENEMY-ORG 
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F.4.2  Concepts  modeled  in  the  JCDB  missing  from  WARSIM 

To  appreciate  the  magnitude  of  the  problem  of  mapping  the  JCDB  into  WARSIM  Object 
Model  classes,  one  need  only  look  at  the  size  of  the  two  models  that  were  examined  in 
this  study.  There  were  a  total  of  26  WARSIM  classes  (in  the  JSIMS  FOM)  with  a  total  of 
248  attributes.  The  JCDB  data  model,  however,  has  242  entities  that  are  not  enumeration 
lists  with  a  total  of  2963  attributes.  Some  of  those  entities  and  attributes  are  modeled  in 
WARSIM  in  structural  ways,  but  an  order  of  magnitude  difference  is  very  hard  to  over¬ 
come. 

One  of  the  main  concepts  in  the  JCDB  is  that  of  a  plan,  but  that  concept  does  not  appear 
in  WARSIM.  There  are  several  other  concepts  in  the  JCDB  that  are  related  to  plans  that 
are  also  missing  from  WARSIM,  such  as  OVERLAY  and  DOCUMENT. 

While  WARSIM  does  model  a  very  limited  set  of  attributes  about  individual  people  that 
are  members  of  a  crew  and  items  of  materiel  that  belong  to  organization,  it  does  not 
model  individual  people  or  things  in  the  fundamental  way  the  JCDB  does.  Similarly, 
while  WARSIM  identifies  the  networks  to  which  an  organization  belongs,  it  does  not 
model  networks  themselves. 

Another  concept  that  is  recorded  in  the  JCDB  but  not  modeled  in  WARSIM  is  the  state  of 
JCDB  updates.  That  is,  as  some  of  the  JCDB  records  are  updated,  their  changes  are 
scheduled  for  transmission  to  other  instances  of  the  JCDB,  and  the  status  of  these  trans¬ 
missions  is  also  recorded  in  the  JCDB.  Thus,  if  a  model  is  supposed  to  simulate  the  op¬ 
eration  of  a  system  that  contains  the  JCDB,  it  should  model  the  state  of  these  transmis¬ 
sions  and  reflect  the  fact  that  different  instances  of  the  JCDB  may  be  in  different  states. 

F.4.3  Differences  in  the  ways  details  are  modeled 

There  are  numerous  cases  where  individual  attributes  are  modeled  differently  between 
WARSIM  and  JCDB.  A  large  block  of  such  differences  can  be  found  in  the  way  features 
and  facilities  are  modeled.  WARSIM  utilizes  the  Terrain  Common  Data  Model  (TCDM), 
which  models  a  long  list  of  features  and  facilities,  each  with  attributes  appropriate  to  that 
specific  feature  or  facility.  The  JCDB,  however,  has  type-specific  attributes  for  very  few 
features  or  facilities,  and  provides  a  few  generic  attributes  for  the  rest.  It  has  enumerated 
lists  of  features  and  facilities  that  aligns  reasonably  well  with  the  list  of  classes  modeled 
in  the  TCDM,  so  one  can  assert  that  most  of  the  features  and  facilities  in  the  TCDM  are 
modeled  in  the  JCDB,  but  not  at  the  same  level  of  detail. 

As  an  example  of  the  many  ways  in  which  a  specific  concept  can  be  modeled,  consider 
direction.  Both  models  have  representations  for  direction,  but  WARSIM  models  it  in  3- 
space  with  a  starting  point  and  ending  point,  while  the  JCDB  models  it  in  2-space,  in 
some  cases  as  16  compass  points  and  in  other  cases  as  a  bearing  angle. 

WARSIM  keeps  counts  of  a  number  of  things,  such  as  the  number  of  platforms  belonging 
to  a  unit.  In  the  JCDB,  these  quantities  have  to  be  computed  by  counting  the  number  of 
appropriate  entries  in  the  appropriate  table.  WARSIM  also  uses  Boolean  variables  to  indi¬ 
cate  the  presence  or  absence  of  various  capabilities  of  platforms  (e.g.,  does  it  have  a  ra- 
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dio).  In  the  JCDB  that  question  ean  only  be  answered  by  examining  all  the  pieees  of 
equipment  assoeiated  with  the  platform  to  see  if  any  of  them  are  radios  and  eheeking  the 
assoeiation  type  to  see  if  the  radio  is  on  the  platform. 

More  importantly,  for  both  eounts  and  Booleans,  moving  data  from  WARSIM  to  the 
JCDB  is  likely  to  require  ereating  instanee  data,  not  just  storing  a  value  somewhere.  For 
example,  if  the  JCDB  data  for  a  unit  does  not  already  indieate  that  it  has  the  required 
number  of  a  partieular  platform,  those  platforms  will  need  to  be  ereated  of  the  right  type, 
and  suitable  assoeiations  ereated  linking  them  to  the  eorreet  unit.  This  is  an  example  of 
the  general  problem  of  “disaggregation”  wherein  something  represented  only  at  an  ag¬ 
gregate  level  (e.g.,  eounts  of  types  of  things)  in  one  eontext  needs  to  be  disaggregated  in 
another.  The  problem  is  that  important  data  (e.g.,  loeation)  on  the  instanees  will  be  miss¬ 
ing  when  they  are  disaggregated. 

F.5  Recommendations 

The  main  result  to  eome  out  of  the  analysis  presented  in  this  appendix  is  the  reeognition 
of  signifieant  differenees  in  the  data  modeled  by  the  WARSIM  portion  of  the  JSIMS  ob- 
jeet  model  and  the  JCDB.  The  degree  to  whieh  this  will  affeet  interoperability  depends  on 
speeifie  data  interehange  needs.  If  mueh  of  the  data  in  either  model  needs  to  be  ex- 
ehanged,  then  at  least  one  model  and  system  may  require  major  rework  beeause  so  many 
of  the  data  elements  and  eodes  in  one  model  are  not  in  the  other.  If  systems  only  need  to 
exehange  a  small  subset  of  eaeh  other's  data,  and  if  it  turns  out  to  be  the  right  subset,  they 
might  get  by  with  minor  adjustments. 

However,  sinee  our  assessments  were  limited  to  the  WARSIM  managed  objeet  elasses 
and  attributes  of  the  JSIMS  FOM  (and  the  TCDM),  we  have  undoubtedly  missed  some 
data  modeling  eapabilities  internal  to  WARSIM  that  are  not  refleeted  in  these  parts  of  the 
JSIMS  FOM.  Thus,  WARSIM  itself  should  provide  somewhat  better  eoverage  of  JCDB 
data  elements  than  our  assessments  indieate.  Unfortunately,  the  internal  software  devel¬ 
opment  models  for  WARSIM  were  not  up  to  date  when  we  started  this  study,  so  the 
JSIMS  FOM  was  our  best  souree  for  identifying  WARSIM  modeling  eapabilities. 

Reaehing  a  better  alignment  of  these  two  models  will  require  a  eoneerted  effort  on  the 
part  of  both  eommunities  working  together.  The  study  aeknowledges  that  this  is  already 
oeeurring  to  some  degree  via  the  Simulation  to  C4I  Interoperability  (SIMCI)  OIPT 
[Army  2002].  In  reeent  informal  diseussions  at  the  Simulation  Interoperability  Workshop, 
representatives  from  the  M&S  eommunity  agreed  that  most  of  the  onus  for  ehange  was 
on  them  to  meet  the  standards  being  set  within  the  C2  eommunity.  We  agree,  but  eaution 
that  the  C2  eommunity  also  needs  to  be  more  aware  of  the  requirements  for  M&S  with 
respeet  to  the  need  to  ineorporate  models  and  simulations  into  C2  deeision  making,  as 
well  as  the  need  to  ineorporate  C2  systems  into  testing  and  training  aetivities. 

It  should  not  be  expeeted  that  a  single  data  model  eould  serve  both  M&S  and  C2  re¬ 
quirements  eompletely  sinee  the  performanee  objeetives  are  frequently  very  different. 
The  real  world  abstraetions  that  are  ineorporated  into  M&S  frequently  ignore  details  of 
interest  to  the  operational  user.  This,  eoupled  with  the  need  to  sometimes  exeeute  in  faster 
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than  real  time,  requires  optimizations  in  the  use  of  data  by  M&S  that  do  not  readily  map 
into  the  operational  data.  As  a  eonsequenee,  it  is  expeeted  that  some  translation  between 
operational  representation  and  simulated  representation  will  always  be  neeessary.  Never¬ 
theless,  signifieant  advaneement  in  the  alignment  of  their  respeetive  models  is  necessary 
if  improvement  in  the  state  of  interoperability  between  these  two  communities  is  to  be 
achieved.  Every  effort  should  be  made  to  reach  agreement  on  the  use  of  data  standards 
wherever  they  make  sense. 

An  essential  step  in  this  process  is  to  reach  an  agreement  on  how  data  standards  are  to  be 
decided.  There  are  two  aspects  to  this  recommendation.  Most  obviously  there  is  a  need  to 
agree  on  a  process  for  meeting  existing  requirements.  However,  it  should  be  recognized 
that  standards  are  primarily  intended  to  facilitate  meeting  future,  unknown  interoperabil¬ 
ity  requirements.  Hence,  the  process  needs  to  consider  standards  that  go  beyond  known 
existing  requirements  to  address  areas  where  standards  are  possible,  even  if  not  yet  re¬ 
quired.  Moreover,  the  process  of  agreeing  to  data  model  standards  should  be  expected  to 
be  an  on-going  one  that  addresses  an  ever-changing  need. 

One  way  to  begin  the  data  model  alignment  process  is  to  examine  the  concepts  modeled 
by  both  existing  models.  There  are  many  concepts  that  are  common  to  both  communities, 
and  there  are  many  that  are  not.  The  zeros  in  Table  F-4  are  generally  good  leads  for  find¬ 
ing  concepts  modeled  in  WARSIM  that  are  not  modeled  in  the  JCDB.  They  may  not  need 
to  be,  but  at  least  that  need  should  be  questioned.  Similarly,  this  study  also  identifies  a 
large  number  of  concepts  and  attributes  modeled  in  the  JCDB  that  are  missing  from 
WARSIM. 

Once  the  concepts  to  be  modeled  in  a  common  way  have  been  agreed  upon,  the  next  step 
is  to  decide  how  each  concept  is  to  be  modeled.  The  current  disparities  between  the  two 
models  are  frequently  extreme.  For  example,  WARSIM  has  only  a  few  attributes  unique 
to  persons  or  crew  members.  And  a  person’s  VOFUME  is  singled  out  as  the  only  distinc¬ 
tive  attribute  of  the  PERSON  TYPE  entity.  While  the  JCDB  does  not  have  that  attribute, 
it  does  have  approximately  175  other  attributes  of  a  person.  This  example  underscores  the 
differences  in  current  requirements  of  the  two  communities,  but  it  is  also  an  example  of 
why  those  models  need  to  be  rethought. 

It  should  also  be  noted  that  we  originally  interpreted  Environmental  Data  Coding  System 
(EDCS)  Classification  Codes  as  being  part  of  the  TCDM.  In  fact  this  is  not  always  the 
case.  During  the  review  of  this  report,  we  learned  that  some  of  our  Value-level  TCDM 
assessments  use  non-TCDM  codes.  Unfortunately  we  did  not  have  the  resources  to  revise 
the  assessments.  Some  assessments  may  therefore  have  a  higher  degree  of  alignment  than 
indicated.  However,  we  do  not  expect  that  the  results  in  Table  F-5  would  change  signifi¬ 
cantly  if  we  were  to  re-conduct  these  assessments. 

F.6  Alignment  detail  tables 

The  tables  which  follow  provide  the  details  of  the  alignment  assessment.  Tables  F-4  to 
F-12  relate  to  aligning  the  WARSIM  object  models  to  the  JCDB.  In  all  of  these  tables  ex¬ 
cept  F-5,  the  column  headings  have  the  following  meanings: 
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•  Attribute  Name  -  Name  of  the  attribute  from  the  WARSIM  objeet  elass 

•  Data  Type  -  Data  type  of  the  attribute  in  the  WARSIM  objeet  elass 

•  Field  Name  -  If  the  Data  Type  is  eomplex,  and  henee,  a  elass,  then  the  field  name 
is  the  name  of  an  attribute  of  that  eomplex  data  type 

•  Data  Type  -  The  seeond  Data  Type  field  is  the  type  of  the  Field  of  the  eomplex 
data  type 

•  Entity  Name  -  The  name  of  a  JCDB  entity 

•  Attribute  Name  -  The  seeond  Attribute  Name  is  an  attribute  of  that  JCDB  entity 

•  Data  Type  -  The  third  Data  Type  field  is  the  data  type  of  the  attribute  of  the  JCDB 
entity 

•  Assessment  -  The  assessment  eolumn  eontains  the  assessment  of  the  mapping  of 
the  speeifie  WARSIM  attribute  or  field  or  the  overall  assessment  of  the  WARSIM 
objeet  elass  (in  shaded  rows).  The  assessment  of  the  WARSIM  objeet  elass  is  de¬ 
termined  by  averaging  the  assessments  of  its  attributes,  ineluded  inherited  attrib¬ 
utes. 

Table  F-5  maps  the  TCDM  features  into  the  eorresponding  eode  table  in  the  JCDB.  Its 
eolumn  headings  have  the  following  meanings. 

•  TCDM  Coverage  -  The  name  of  a  high-level  “eoverage”  area  in  the  TCDM  whieh 
groups  featues  of  a  similar  type 

•  Subeoverage  -  The  name  of  a  more  speeifie  subeoverage  area  in  the  TCDM 
whieh  provides  subgroupings  of  featues  in  a  eoverage 

•  Feature  Code  -  The  eode  used  to  represent  a  speeifie  feature  in  the  TCDM  whieh 
fits  into  the  Coverage  and  Subeoverage  (if  any)  groupings  of  the  prior  eolumns 

•  Feature  Name  -  The  name  used  to  represent  a  speeifie  feature  in  the  TCDM  speei- 
fied  by  the  Feature  Code  of  the  prior  eolumn 

•  JCDB  File  Name  -  The  name  of  the  eode  table  in  the  JCDB  whieh  eontains  an 
enumeration  value  whieh  eorresponds  to  the  feature  identified  in  the  TCDM  eol¬ 
umns. 

Note  that  the  JCDB  File  Name  eolumn  may  eontain  multiple  entries  when  a  single 
TCDM  feature  maps  into  multiple  eodes  in  the  JCDB.  And,  this  eolumn  eontains  the  text 
“N/M”  when  no  mapping  exists  for  the  TCDM  eode.  Question  mark  entries  are  used  to 
indieate  an  inability  to  determine  whether  or  not  a  suitable  mapping  exists. 

Tables  F-13  to  F-19  relate  to  aligning  the  JCDB  with  the  WARSIM  objeet  model.  In  these 
tables,  the  eolumn  headings  have  the  following  meanings: 

•  Attribute/  Assoeiation  Name  -  The  name  of  an  attribute  or  an  assoeiation  of  that 
JCDB  entity 

•  Key  Assoeiation  Attribute  -  Where  the  seeond  eolumn  identifies  an  assoeiation, 
this  eolumn  names  the  attribute  of  that  assoeiation  used  for  the  assessment 

•  Data  Type  -  The  data  type  of  the  JCDB  attribute  identified  in  the  seeond  or  third 
eolumn 

•  Class  -  The  name  of  a  WARSIM  objeet  elass 

•  Attribute  -  The  attribute  of  the  WARSIM  elass  that  most  elosely  aligns  with  the 
identified  JCDB  attribute 
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•  Data  Type  -  The  data  type  of  the  WARSIM  attribute 

•  Assessment  -  The  first  assessment  column  is  the  assessment  of  the  mapping  of 
the  specific  JCDB  attribute  to  the  WARSIM  object  model  or  the  overall  assess¬ 
ment  of  the  JCDB  entity,  determined  by  averaging  the  assessments  of  the  attrib¬ 
utes. 

Certain  rows  are  shaded  in  some  of  these  tables  to  identify  the  row  as  containing  the 
evaluation  for  the  whole  entity/class  whose  attributes  follow. 


F-22 


Table  F-4.  Mapping  WARSIM  unit  area  to  JCDB 

_ _ WARSIM _ _ JCDB _ _ Assess- 

Attribute  Name  Data  Type  Field  Name  Data  Type  Entity  Name  Attribute  Name  Data  Type  ment 


symbol  code  o _ string _ org  type  symbol  symbol  code _ enumerated  90 

uic _ string _ oi^ _ name  uic _ string _ 100 


Attribute  Name  Data  Type  Field  Name  Data  Type  Entity  Name  Attribute  Name  Data  Type 


Attribute  Name  Data  Type  Field  Name  Data  Type  Entity  Name  Attribute  Name  Data  Type 


enumerated 


Attribute  Name  Data  Type  Field  Name  Data  Type  Entity  Name  Attribute  Name  Data  Type 


uO _ double 

^j1 _ double 

velocityparallel _ double 

velocityperpendicular  double 


Attribute  Name  Data  Type  Field  Name  Data  Type  Entity  Name  Attribute  Name  Data  Type 


radius  double 


Attribute  Name  Data  Type  Field  Name  Data  Type  Entity  Name  Attribute  Name  Data  Type 
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Table  F-5.  Mapping  TCDM  Features  into  the  JCDB 


JCDB  File  Name 

lndfeat_surfce_cd 

?? 

N/M 

N/M 

lndfeat_roughness 

N/M 

N/M 

N/M 

N/M 

N/M 

lndfeat_vegchar_cd 

fac  type  symbol  or  matitem  sup  class 

Swamp  -  Indfeat  shorin  cat.  Marsh  -  Indfeat  shorin  cat 

N/M 

N/M 

Brush  -  lndfeat_vegchar_cd 

lndfeat_vegchar_cd 

N/M 

N/M 

Airport  -  airport,  fac_cat_cd,  fac_subcat_cd.  Airfield  - 
fac_subcat_cd,  fac_typ_symbol,  feat_symbol_cd. 

N/M 

Apron  -  feat_symbol_cd 

N/M 

fac_typ_symbol 

TCDM  Feature  Name 

exposed  bedrock 

ground  surface  element 

volcanic  dike 

salt  pan 

sand  dune 

sebkha 

snow  field 

Bamboo/Cane 

Clear  way/Cutline/firebreak 

Cropland 

Grassland 

Hops 

Marsh/Swamp 

Orchard/Plantation 

Ricefield 

Scrub/Brush/Bush 

Trees 

Tundra 

Vineyards 

Airport/ Airfield 

Amusement  Park 

Apron/Hardstand 

Assembly  Plant 

Building 

Feature 

Code 

o 

CO 

o 

< 

CO 

DA0 10 

DB160 

BH150 

DB170 

BH160 

BJ100 

o 

o 

O 

UJ 

o 

o 

O 

UJ 

o 

o 

< 

UJ 

EB010 

EA055 

BH095 

o 

o 

< 

UJ 

BH135 

EB020 

o 

CO 

o 

O 

UJ 

BJ110 

o 

LO 

O 

< 

UJ 

GB005 

AK030 

GB015 

o 

o 

UJ 

< 

ALOIS 

0) 

O) 

«s 

0) 

> 

o 

o 

3 

(0 

>% 

Q. 

03 

L_ 

D) 

O 

'(/) 

>% 

Q_ 

Vegetation 

Urban 

TCDM  Coverage 

Surface  Areals 
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JCDB  File  Name 

River  -  fac_typ_symbol,  wet_rte_typ_cd.  Stream 

fac  typ  symbol,  wet  tie  typ  cd 

§ 

z 

Spring  -  fac_typ_symbol 

fac_typ_symbol 

N/M 

Fill  -  fac_typ_symbol 

N/M 

Silo  -  fac_typ_symbol 

N/M 

N/M 

lndfeat_roughness 

N/M 

N/M 

fac_typ_symbol,  feat_cat_cd,  rte_access_cd 

Pipeline  -  fac_subcat_cd,  fac_typ_symbol.  Pipe 

fac  subcat  cd,fac  typ  symbol 

lndfeat_roughness 

N/M 

N/M 

N/M 

N/M 

N/M 

feat  symbol  cd,  Indfeat  roughness,  protct  leve  cd 

fac  typ  symbol 

N/M 

TCDM  Feature  Name 

River  /  Stream 

River  /  Stream  Centerline  /  Nexus 

Spring  /  Water  Hole 

Well 

Bluff  /  Cliff  /  Escarpment 

Embankment  /  Fill 

Fault 

Grain  Bin  /  Silo 

Grain  Elevator 

Gully  /  Gorge 

Hedgerow 

Ice  Cliff 

Irrigation  Ditch 

Miscellaneous  Obstacle 

Pipeline  /  Pipe 

Quarry 

Rock  Strata  /  Rock  Formation 

Seawall 

Terrain  Cut 

Terrain  Depression 

Volcanic  Dike 

Wall 

Anchorage 

Bottom  Characteristics 

Feature 

Code 

BH140 

o 

N 

CQ 

BH170 

AA050 

DB010 

DB090 

DB110 

o 

CM 

o 

< 

o 

CO 

o 

< 

DB200 

o 

CM 

o 

< 

UJ 

BJ040 

o 

CO 

o 

I 

CQ 

DB145 

CO 

a 

< 

AA012 

DB160 

BB230 

DB070 

o 

00 

o 

m 

Q 

DB190 

AL260 

BB010 

o 

o 

LL 

CQ 

0) 

O) 

«s 

0) 

> 

o 

o 

3 

(0 

TCDM  Coverage 

Linear  and  Areal  Ter¬ 
rain  Obstacles 

Maritime  Trafficability 
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Attribute  Name  Data  Type  Field  Name  Data  Type  Entity  Name  Attribute  Name  Data  Type 
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Attribute  Name  Data  Type  Field  Name  Data  Type  Entity  Name  Attribute  Name  Data  Type 
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Attribute  Name  Data  Type  Field  Name  Data  Type  Entity  Name  Attribute  Name  Data  Type 
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Attribute  Name  Data  Type  Field  Name  Data  Type  Entity  Name  Attribute  Name  Data  Type 


_ longitude _ double _ 

fire  restricted  areas  spatial  area  c _ coordinates _ ser  coordinate 

fire  threshold  double 
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Table  F-7.  Mapping  org.land.supply_cache  to  JCDB 


Q) 

0 

£ 

£ 

D 

D 

C 

C 

0 

0 

O 

O 

x 

D) 

X 

0  "O 

C 

0 

■o  0 

■O 

.£  0 

to 

c 

O) 

O 


O) 

O 


O) 

O 


O) 

O 


J  O 


^1  <D 


UJ  c 

E 

<  £ 


O) 

o 


O) 

o 


Q. 

£ 


■g 

■^1 

o 


Q. 

£ 
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Table  F-8.  Mapping  platform.shelter.equipment  to  JCDB 


ect  Class:  platform. shelter 


< 
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Table  F-9.  Mapping  minefield. land  to  JCDB 
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Table  F-10.  Mapping  abstract.land.equip_type  to  JCDB 


Assessment 

CO 

in 

50 

o 

CO 

CD 

V/N 

06 

06 

06 

06 

06 

06 

too 

o 

CO 

too 

o 

o 

too 

o 

o 

too 

o 

o 

o 

JCDB 

Data  Type 

string,  string, 
number,  string, 
string 

number,  num¬ 
ber 

number 

number 

number 

number 

Attribute  Name 

midb_be_number  and  midb_o_suffix  and 
midb_cat_number  and  midb_enemy_unitjd 

and  midb  fac  name 

matjtm_  indx  and  matjtm_  input 

crew  qty  ea 

pasngr  qty  ea 

equipt  wdth  dim  m 

equipt  ht  dim  m 

Entity  Name 

o 

O) 

CO 

■^1 

■O 

B 

o 

Q. 

Q. 

D 

CO 

equip_type 

vehicle  type 

Object  Class:  abstract.land.equipment_type 

vehicle  type 

equip  type 

equip  type 

WARSIM 

Data  Type 

Object  Class:  abstract 

base  classification  e 

string 

Ui 

c 

to 

Object  Class:  abstract,  land 

Field  Name 

base  classification 

o 

B 

to 

CD 

> 

CO 

o 

D 

o 

CD 

CO 

o 

CO 

CD 

■O 

O 

o 

c 

D 

o 

o 

D 

o 

CD 

CO 

Data  Type 

O) 

c 

to 

id_c 

CO 

£ 

D 

O 

CD 

CO 

boolean 

boolean 

boolean 

boolean 

boolean 

boolean 

boolean 

long 

string 

long 

double 

double 

double 

string 

double 

double 

double 

double 

double 

Attribute  Name 

c 

o 

to 

c 

D) 

’co 

CD 

C 

CD 

£ 

Q. 

’d 

CT 

CD 

id_u 

security_mark_o 

eg  restart 

radio  capability 

terminal  capability 

sensor  capability 

weapon  capability 

radar  capability 

ir  capability 

crew  size 

model 

passengers 

cargo  height 

wet  cargo 

width 

signature  type 

radar  cross  section 

height 

dry  cargo 

cargo  width 

cargo  length 
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Table  F-11.  Mapping  abstract.land.personnel_type  to  JCDB 


Assess 

merit 

CO 

in 

09 

o 

o 

CO 

V/N 

06 

06 

06 

06 

06 

06 

100 

o 

CO 

o 

JCDB 

Data  Type 

string,  string,  num¬ 
ber,  string,  string 

number,  number 

number 

Attribute  Name 

midb_be_number  and  midb_o_suffix  and 

midb_cat_number  and  midb_enemy_unitjd  and 

midb  fac  name 

mat  itm  indx  and  mat  itm  input 

crew  qty  ea 

Entity  Name 

sup- 

ported_target 

equip  type 

vehicle  type 

WARSIM 

Data  Type 

Object  Class:  abstract 

base_classifica- 

tion_e 

string 

string 

Object  Class:  abstract,  land 

Object  Class:  abstract.land.personnel  type 

Field  Name 

base_classification 

security  caveats  o 

secu¬ 
rity  country  codes  o 

Data  Type 

string 

id  c 

secu- 

rity_mark_c 

boolean 

boolean 

boolean 

boolean 

boolean 

boolean 

boolean 

long 

string 

double 

Attribute  Name 

equip- 

ment_designation 

id  .  u 

security_mark_o 

eg  restart 

radio  capability 

terminal  capability 

sensor  capability 

weapon  capability 

radar  capability 

ir_capability 

0) 

N 

’co 

5 

o 

o 

model 

volume 
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Table  F-13.  Mapping  ORG  to  WARSIM 


Assessment 

CD 

CO 

09 

o 

o 

100 

o 

09 

o 

100 

100 

o 

o 

o 

o 

o 

o 

42 

CO 

CO 

o 

CO 

o 

o 

o 

o 

CO 

o 

o 

CD 

o 

30 

WARSIM 

Data  Type 

string 

string 

string 

string 

string 

complex 

string 

id  c 

id  c 

id  c 

id  c 

[see  ORG  CAPABILITY  EST  below] 

id  c 

X 

0 

Q. 

£ 

o 

o 

Attribute 

factionjd 

uic 

idu 

name 

parentorg 

move  data 

o 

CO 

CO 

0 

■O 

■O 

CD 

0 

c 

'£ 

0 

mtp  network  ids  o 

CO 

O) 

o 

0 

0 

c 

o 

D 

CO 

supported  orgs  o 

supporting  orgs  o 

’c 

D 

O) 

c 

Q. 

0 

O 

distributionjists,  distribution_table,  frequency,  termi- 

Class 

O) 

o 

erg 

org 

org 

org. land 

org 

'c 

D 

■d 

c 

0 

CT 

O 

org 

’c 

D 

■d 

c 

0 

CT 

O 

’c 

D 

■d 

c 

0 

CT 

O 

’c 

D 

■d 

c 

0 

CT 

O 

JCDB 

0) 

a 

> 

H 

(0 

(0 

Q 

Entty  Name:  ORG 

■O 

B 

2 

o 

£ 

D 

C 

0 

enumerated 

number 

string 

string 

number 

number 

string 

string 

enumerated 

date 

string 

number 

complex 

complex 

complex 

complex 

■o 

0 

0 

0 

£ 

D 

C 

0 

complex 

enumerated 

■o 

0 

0 

0 

£ 

D 

C 

0 

enumerated 

enumerated 

enumerated 

enumerated 

enumerated 

■o 

0 

0 

0 

£ 

D 

C 

0 

0) 

3 

n 

3 

u 

c 

o 

(0 

o 

o 

(A 

> 

0) 

org  assc  typ  cd 

ORG  CAPABILITY  EST 

orgdoc  relat  typ 

org  enemy  assc  cd 

orgfac_assc_typ_cd 

orgfeat  assctyp  cd 

orgmat  assc  typ  cd 

oma  typ  cd 

oma  reg  redines  cd 

orgnet_relat_typ 

0) 

E 

(0 

z 

c 

,o 

(0 

o 

o 

(/i 

s. 

3 

n 

AFFILIATION  .CD 

COUNTRY 

DISSEM_LEVEL_CD 

Oin  31AIVN 

ORG..FORML_ABB.NM 

ORGJD 

ORG..INPUT.ID 

ORG _ NAME 

ORG _PARENT_ NAME 

RECORD  .STATUS 

RECORD  _STATUS.DTTM 

SRC_CD 

URN 

ACTOBJ  ORG 

ACTRES  ORG 

FRND  ORG  PT 

ORG  ADD 

ORG  ASSC 

ORG  DOC 

ORG  ENEMY  ASSC 

ORG_FAC 

ORG..FEAT 

ORG..  MAT 

ORG.MISS . AREA 

ORG_NTWRK 
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Assessment 

o 

o 

o 

in 

CsJ 

o 

50 

o 

o 

o 

o 

o 

50 

in 

in 

CO 

09 

09 

09 

o 

o 

o 

WARSIM 

Data  Type 

[seeORG  OPL  STAT  below] 

[see  ORG  TASK  below] 

enumerated 

enumerated 

target_prlorltyJlst  (string) 

string 

string 

string 

long 

Attribute 

0  P!  |BU 

echelon 

type 

alr_rules_of_engagement_o  or 

ground  rules  of  engagement  o 

o 

CO 

o 

■> 

CO 

<D 

CO 

B 

C 

B 

CO 

CO 

CD 

c 

70 

CO 

2 

Class 

■o 

c 

CO 

1 

O) 

o 

■o 

c 

CO 

1 

O) 

o 

’c 

D 

■d 

c 

_co 

o 

’E 

D 

■d 

c 

_co 

Ui 

o 

’E 

D 

■d 

c 

B 

o 

'E 

D 

■d 

c 

_co 

o 

'E 

D 

■d 

c 

_co 

o 

JCDB 

0) 

a 

> 

H 

(0 

(0 

Q 

complex 

enumerated 

enumerated 

complex 

enumerated 

■O 

B 

2 

o 

£ 

D 

C 

CD 

enumerated 

■O 

B 

2 

o 

£ 

D 

C 

CD 

enumerated 

enumerated 

string 

enumerated 

enumerated 

enumerated 

■O 

B 

2 

o 

£ 

D 

C 

CD 

Entity  Name:  ORG_CAPABILITY_EST 

■O 

B 

2 

o 

£ 

D 

C 

<D 

enumerated 

enumerated 

enumerated 

number 

number 

number 

Entity  Name:  ORG_OPL_STAT 

■o 

B 

2 

o 

£ 

D 

C 

<D 

■O 

B 

2 

o 

£ 

D 

C 

CD 

■O 

B 

2 

o 

£ 

D 

C 

CD 

enumerated 

enumerated 

enumerated 

0) 

3 

n 

3 

c 

_o 

(0 

o 

o 

(A 

s. 

> 

0) 

orgper  assc  typ 

ctll  Ind  cd 

funct  role  cd 

echelon_cd 

msn  specialty 

msn_cd 

moblllty_cd 

ob  type 

orgt  rmk  txt 

plan  org  role  cd 

rank_cd 

post  typ  cd 

trgt_org_assc_cd 

0) 

E 

(0 

z 

c 

,o 

(0 

o 

o 

(A 

s. 

3 

'C 

ORG  OPL  STAT 

ORG  PER 

ORG  PERTYP  TRKNG 

ORG  TASK 

ORG  TYPE 

PLAN  ORG 

POST 

TRGT_ENG_ORG_ASSC 

CAPA..CAT  CD 

CAPA.UM  RATE.  CD 

CAPA  .QUAL_CD 

CAPA_UM  CD 

> 

1 — 
O 

< 

D. 

< 

o 

PERCEP  REFJNDX 

PERCEPJNPUT  ID 

CRNT_ACTIVITY_CD 

PRJCTD  ACTIVITY  CD 

ORG  CBAT  REDINESS 

ORG  COMBAT  INT  CD 

WEAPONS  CTRL  CD 

OPL  ENVIRO  CD 
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Assessment 

09 

o 

o 

o 

09 

o 

o 

06 

o 

o 

o 

o 

o 

o 

o 

o 

o 

o 

o 

o 

o 

o 

o 

o 

o 

WARSIM 

Data  Type 

long 

long 

string 

Attribute 

0) 

> 

0) 

1 

CL 

■O 

CL 

CO 

CO 

CD 

c 

CD 

> 

o 

CD 

It 

CD 

C 

o 

'co 

CO 

£ 

CD 

> 

B 

CL 

CL 

O 

£ 

Class 

’c 

D 

■d 

c 

d) 

o 

’c 

D 

■d 

c 

ro 

P 

o 

'c 

D 

■d 

c 

B 

Ui 

o 

JCDB 

0) 

a 

> 

H 

(0 

(0 

Q 

■O 

o 

2 

o 

£ 

D 

c 

0) 

enumerated 

enumerated 

enumerated 

■O 

B 

2 

o 

£ 

D 

C 

CD 

enumerated 

text 

■o 

B 

2 

o 

£ 

D 

C 

CD 

number 

number 

Entity  Name:  ORG  TASK 

enumerated 

enumerated 

enumerated 

enumerated 

date 

date 

number 

number 

enumerated 

enumerated 

string 

0) 

3 

n 

3 

c 

_o 

(0 

o 

o 

(A 

s. 

> 

0) 

0) 

E 

(0 

z 

c 

,o 

(0 

o 

o 

(A 

s. 

3 

£ 

'C 

ORG_EXPOSURE_LVL 

ORGOP  RENFRC  CD 

ORG  REDINES  CNDTN 

ORG  RADS  QTY  CD 

ORG  COMBAT  EFF  CD 

ORG  AD  WARNG  CD 

OPSTAT  AMP  TXT 

MOPP  LVL  CD 

PERCEP  REF  INDX 

PERCEPJNPUTJD 

RECORD  STATUS 

RECORD  STATUS  DTTM 

DISSEM_LEVEL_CD 

ORGTSK  TYP.CD 

CANTPRO  CD 

ORGTSK. ENEMY  ACT 

ORGTSK  ASSC. CAT 

ORGTSK  STRT  DTTM 

ORGTSK  END.  DTTM 

ORGTSK  .PHASE  NO 

ORGTSK  PHSEDUR 

ORGTSK  .REQ.  CAT.  CD 

ORGTSK_REQ_SUBCAT 

ORGTSK  SUPREQ  TXT 
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Table  F-14.  Mapping  MAT  to  WARSIM 


C/D 

Q 

C/D 

Q 

1 — 

O 

< 

O 

X 

_l 

O 

CL 

Q 

Z 

LU 

9 

X 

H 

Dc' 

O 

u 

O 

CD 

CO 

X 

H 

< 

1— 

3 

o 

CO 

CO 

o 

<<■ 

< 

LU 

LU 

CO 

CO 

Z 

H 

Q 

DC 

1 _ 

Q 

LU 

LU 

CL 

H 

H 

H 

H 

H 

o 

H 

_l 

H 

H 

H 

H 

O 

< 

DC 

< 

< 

< 

< 

LU 

CD 

DC 

LO 


lAiiia  snivis  ayo33y 
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Comment 

The  Identification  of  platforms  with  organizations  In  WARSIM  Is  only 

from  the  organization  side.  The  only  relationship  supported  Is  ''owned” 

and  none  of  the  other  attributes  of  holdings  are  supported.  | 

Assess 

ment 

o 

Data 

Type 

WARSIM 

Attribute 

Class 

Data 

Type 

OQ 

Q 

Key  Association 

Attribute 

(3 

z 

Q 

_i 

O 

X 

O 

“5 

Attribute/ 

Association  Name 

SBJCT  EMAT  INPUT 

EMAT  ASSC  CD 

SBEQUIP  MASTER  KEY 

OBEQUIP  MASTER  KEY 

MLS  CLASSIFICATION 

RECORD_STATUS 

RECORD  STATUS  . DTTM 

DISSEM  . LEVEL  CD 

PERCEP  REF.  INDX 

PERCEP.INPUT  ID 

H 

< 

LU 

Z 

LU 

CD 

E 

CO 

z 

c 

LU 

EORG_MAT_HLDNJNDX 

ENEMY. MAT.  INDX 

EORG.  INDX 

EORG  INPUT  ID 

ENEMY  MAT.  INPUT 

QTY.  EQUIP 

AID  TdO  ONCTHliVIAI 

Q 

LU 

o 

1 — 
CO 
LU 
Q 

1 — 
o 

Q 

LU 

O 

< 

< 

Q 

1 — 
o 

EORG  HLDNG  AMP  TXT 

MLS  CLASSIFICATION 

PERCEP  REF  INDX 

PERCEP  INPUT  ID 

RECORD  STATUS 

RECORD  STATUS  DTTM 

DISSEM_LEVEL_CD 
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Comment 

WARSIM  does  not  support  any  of  the  attributes  of  enemy  mat  opi  stat 

WARSIM  platform  move  data  supports  multiple  move  segments,  each 
of  which  has  a  base  point 

These  keys  are  supported  structurally  in  WARSIM 

WARSIM  only  has  a  stored  location  for  a  specific  time,  with  subsequent 
positions  calculated  based  on  movement  type 

Calculated  positions  are  assumed  to  be  accurate 

Course  angle  can  be  calculated  from  head  and  tail  locations 

Not  modeled 

Assess 

ment 

O 

49 

o 

o 

o 

o 

too 

o 

o 

o 

05 

too 

o 

O 

WARSIM 

Data 

Type 

coordi- 

nate_ 

3d_c 

double 

Attribute 

direction. head/tail 

speed 

Class 

platform. 

move_data. 

ground_ 

linear 

platform. 

move_data. 

ground_ 

linear 

JCDB 

Data 

Type 

Entity  Name:  ENEMY_MAT_OPL_STAT 

Entity  Name:  ENEMY_MAT_PT 

enumer¬ 

ated 

number 

number 

Key  Association 

Attribute 

Attribute/ 

Association  Name 

ENMAT  OPLSTAT  INDX 

ENEMY  MAT  INDX 

ENEMY  MAT  INPUT 

CONDITION 

AVAILABILITY_CD 

OPER  STATUS 

> 

1 — 
o 
< 

PERCEP  REF  INDX 

PERCEP  INPUTJD 

RECORD  STATUS 

RECORD  STATUS  DTTM 

DISSEM  LEVEL  CD 

XCNI  id  iVlAI  A1AI3N3 

ENEMY  MAT.  INDX 

ENEMY.MAT  ..INPUT 

LOC_ASSC_CD 

ACCURACY  QTY 

COURSE 

SPEED_KMH 

< 

O 

Q 

O 

O 

O 

EQUIP  QTY 
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Comment 

WARSIM  platform  move  data  supports  multiple  move  segments,  each 
of  which  has  a  base  point 

WARSIM  platform  move  data  supports  multiple  move  segments,  each 
of  which  has  a  base  point 

These  keys  are  supported  structurally  In  WARSIM 

WARSIM  only  has  a  stored  location  for  a  specific  time,  with  subsequent 
positions  calculated  based  on  movement  type 

Calculated  positions  are  assumed  to  be  accurate 

Course  angle  can  be  calculated  from  head  and  tall  locations 

Assess 

ment 

100 

100 

100 

100 

o 

o 

o 

o 

o 

52 

o 

o 

o 

o 

o 

o 

100 

o 

o 

o 

05 

WARSIM 

Data 

Type 

double 

(3) 

double 

(3) 

double 

double 

(3) 

coordl- 

nate_3 

d_c 

Attribute 

constant_position 

constant_posltlon 

altitude 

constant_posltlon 

direction. head/tall 

Class 

plat¬ 
form,  move 

data 

plat¬ 
form,  move 

data 

plat¬ 
form,  move 

_data.grou 

nd  linear 

plat¬ 
form,  move 

data 

plat¬ 
form,  move 

_data.grou 

nd  linear 

JCDB 

Data 

Type 

number 

number 

number 

number 

Entity  Name:  ENEMY_MAT_PT_HIST 

enumer¬ 

ated 

number 

Key  Association 

Attribute 

Attribute/ 

Association  Name 

EN_MAT_PT_LAT 

NOT  id  iVIAI  N3 

ALTITUDE_M 

ELEVATION_M 

PERCEP  REF  INDX 

PERCEP  INPUT  ID 

RECORD  STATUS  DTTM 

DISSEM  LEVEL  CD 

RECORD_STATUS 

XCNI  iSIH  id  iVIAIN3 

XCNI  id  iVIAI  AIAI3N3 

ENEMY. MAT JNDX 

ENEMY.MAT  ..INPUT 

LOC_ASSC_CD 

ACCURACY  .QTY 

COURSE 
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Comment 

Not  modeled 

WARSIM  does  not  model  Individual  people 

Assess 

ment 

100 

o 

O 

100 

100 

100 

100 

o 

o 

o 

o 

o 

o 

WARSIM 

Data 

Type 

double 

double 

(3) 

double 

(3) 

double 

double 

(3) 

Attribute 

speed 

constant_posltlon 

constant_posltlon 

altitude 

constant_posltlon 

Class 

plat¬ 
form,  move 

_data.grou 

nd  linear 

plat¬ 
form,  move 

data 

plat¬ 
form,  move 

data 

plat¬ 
form,  move 

_data.grou 

nd  linear 

plat¬ 
form,  move 

data 

JCDB 

Data 

Type 

number 

number 

number 

number 

number 

Entity  Name:  EN_PER_EN_MAT 

Key  Association 

Attribute 

Attribute/ 

Association  Name 

SPEED_KMH 

< 

O 

Q 

O 

O 

O 

EQUIP  QTY 

EN_MAT_PT_LAT 

NOT  Id  iVIAI  N3 

ALTITUDE_M 

ELEVATION_M 

PERCEP  REF  INDX 

PERCEPJNPUTJD 

RECORD  STATUS  DTTM 

DISSEM  .LEVEL.CD 

RECORD  STATUS 

E_PER_E_MAT_INDX 

ENEMY  MAT  INDX 

E_PERSONJNDX 

ENEMY  MAT  INPUT 

E  PERSON  INPUT 

EPER  EMAT  ASSC  CD 
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Comment 

WARSIM  does  not  model  relationships  between  facilities  and  materiel 

WARSIM  has  no  concept  of  a  candidate  target 

Assess 

ment 

o 

o 

WARSIM 

Data 

Type 

Attribute 

Class 

JCDB 

Data 

Type 

Entity  Name:  FAC_EN_MAT 

Entity  Name:  CNDT_TRGT 

Key  Association 

Attribute 

Attribute/ 

Association  Name 

EQUIP  MASTER  KEY 

INDIVID  MASTER  KEY 

MLC  CLASSIFICATION 

RECORD  STATUS 

RECORD  STATUS  DTTM 

DISSEM_LEVEL_CD 

PERCEP  REF  INDX 

PERCEP  INPUT  ID 

FAC  JNDX 

ENEMY  MAT  INDX 

FAC  .INPUT  ID 

ENEMY  MAT  INPUT 

FAC_EN_MAT_ASSC_CD 

FAC  MASTER  KEY 

EQUIP  MASTER  KEY 

MLS  CLASSIFICATION 

PERCEP  REF  INDX 

PERCEP  INPUT  ID 

RECORD  STATUS 

RECORD_STATUS_DTTM 

DISSEM  LEVEL  CD 

CTRGT  INDX 

CTRGT  INPUT  ID 

CTRGT  FOCUS  TYP  CD 

TRGT  SYMBOL  CD 

EORG  INDX 

EORG  INPUT  ID 

ENEMY  MAT  INDX 

ENEMY  MAT  INPUT 
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Comment 

WARSIM  has  no  concept  of  an  event 

Assess 

ment 

o 

WARSIM 

Data 

Type 

Attribute 

Class 

JCDB 

Data 

Type 

Entity  Name:  EN_MAT_EVENT 

Key  Association 

Attribute 

Attribute/ 

Association  Name 

E  PERSON  INDX 

E  PERSON  INPUT 

FEAT  INDX 

FEAT  INPUT  ID 

FAC  INDX 

FACJNPUTJD 

PRIORITY  CD 

MSN  VALUE 

CTRGTVCNTY  DUR 

CTRGT.LENGTH  DIM  M 

CTRGT  WIDTH  DIM  M 

CTRGT_  RADIUS . DIM  M 

CTRGT  HEIGHT . DIM  M 

CTRGT  ATTITUD. MILS 

1 — 
X 
H 

CL 

< 

1 — 
o 

DC 

1 — 
o 

COMMON  TRGT.NUM 

HULTEC  NUMBER 

ABCA  NO 

RECORD  STATUS  DTTM 

RECORD  STATUS 

DISSEM_LEVEL_CD 

E  MAT  EVNT  INDX 

ENEMY  MAT  INDX 

EVENT  INDX 

ENEMY  MAT  INPUT 

EVENT  INPUT 

EMAT  EVENT  ASSC  CD 

EVENT  MASTER  KEY 

EQUIP  MASTER  KEY 

MLS  CLASSIFICATION 
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Table  F-16.  Mapping  MATJTEM  to  WARSIM 


Comment 

matjtem  aligns  with  abstract. land. equipment_ type 

The  distinction  between  consumables  and  equipment  is  not  modeled  in  WAR¬ 
SIM 

WARSIM  does  not  model  the  supply  class  of  materiel  types 

Not  modeled  by  Warsim 

It  is  not  clear  that  the  intention  of  model  is  to  serve  as  a  name 

WARSIM  only  offers  MIDB  as  the  description  of  a  materiel  type 

The  relationship  between  two  materiel  types  is  not  modeled  in  WARSIM 

Assess¬ 

ment 

in 

09 

09 

o 

o 

o 

in 

o 

o 

o 

o 

o 

o 

o 

WARSIM 

Data 

Type 

Entity  Name:  MATJTEM 

string 

string 

string 

Entity  Name:  MAT_ITEM_ASSC 

Attribute 

id  u 

id  u 

model 

(A 

(A 

(0 

O 

abstract 

abstract 

abstract.land 

JCDB 

0) 

a 

> 

H 

(0 

(0 

Q 

number 

number 

string 

Attribute  Name 

MAT_ITM_INPUT 

XQNI  lAlil  iVIAI 

ao  iVO  lAliliVIAI 

MATITEM.  SUP  CLASS 

BRIL  TRACK  IND.  CD 

MATITM  NAME 

MATITM  . TECH  JD 

MATITM. DESCR.  TXT 

MATITEM.  SYMBOL  CD 

RECORD  STATUS 

RECORD_STATUS_DTTM 

DISSEM  LEVEL  CD 

MAT  ITM  ASSC  INDX 

SBJCT  MAT  ITM  INDX 

OBJCT  MAT  ITM  INDX 

OBJCT  MATITM  INPUT 

SBJCT  MATITM  INPUT 

MAT  ITEM  ASSC  TYP 

MATITEM  GRP  NOMEN 

> 

1 — 
O 

X 

< 

o 

CO 

< 

1- 

1- 

< 

MAT  ASSC  STRT  DTTM 

M AT_AS  SC_E  N  D_DTTM 

RECORD  .STATUS 

RECORD  .STATUS. DTTM 

DISSEM  LEVEL.  CD 
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Comment 

Materiel  item  holdings  for  an  organization  are  aligned  with  org. land. unit. 
org.land.equip_group  can  be  used  when  it  is  a  subordinate  org 

WARSIM  does  not  have  a  generic  ''damaged”  kill  type 

Assess¬ 

ment 

CN 

CN 

09 

09 

09 

09 

100 

in 

o 

100 

o 

in 

o 

in 

o 

o 

o 

o 

o 

o 

o 

o 

o 

o 

o 

o 

o 

o 

o 

o 

WARSIM 

Data 

Type 

Entity  Name:  MAT_ITEM_HOLDINGS 

string 

string 

string 

string 

long 

[counted] 

long 

[counted] 

[counted] 

Attribute 

D 

;g 

D 

;g 

D 

;g 

D 

;g 

num- 

ber_of_platforms 

0) 

Q. 

15 

e' 

S 

CO 

Q. 

author- 

ized_equipment_c 

CD 

Q. 

15 

e' 

S 

CO 

Q. 

(D 

Q. 

15 

e' 

1 

"co 

Q. 

(A 

i/i 

(0 

O 

abstract 

abstract 

org 

org 

Q. 

D 

O 

O) 

D 

CT 

q 

■d 

c 

ro 

o 

Q. 

D 

O 

D) 

Q. 

'd 

CT 

q 

■d 

c 

ro 

CT 

o 

org. land. unit 

Q. 

D 

O 

Ui 

Q. 

'd 

CT 

q 

■d 

c 

ro 

CT 

O 

Q. 

D 

O 

Ui 

Q. 

'd 

CT 

q 

■d 

c 

ro 

CT 

O 

JCDB 

0) 

a 

> 

H 

(0 

(0 

Q 

number 

number 

number 

number 

number 

number 

number 

number 

number 

number 

Attribute  Name 

MAT  ITM  INPUT 

MAT  ITM  INDX 

ORG  ID 

ORG  INPUT  ID 

AID  ONCTHliVlAI 

MATIHLDNG  OPL..QTY 

MATITEM  SUP  CLASS 

AID  HinV  lAliliVlAI 

QTY. DAMAGED 

QTY  ..RECUP 

QTY. DESTROYED 

MATI  DAYS  QTY 

RE  PO  RT .  ACTUAL ..  DTTM 

DUEIN_QTY..CURRENT 

DUEIN...QTY.  D1 

DUEIN_QTY_.D2 

DUEIN.QTY  D3 

DUEIN.QTY  .D4 

DUE  IN.  QTY  D30 

DUEIN_QTY_D60 

DUEIN  QTY  D90 

HLDNGS  AMP  TXT 

PERCEP  INPUT  ID 

PERCEP  REF  INDX 

RECORD  STATUS 

RECORD  STATUS  DTTM 

DISSEM  LEVEL  CD 
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Comment 

WARSIM  does  not  model  materiel  Item  consumption 

WARSIM  does  not  model  materiel  held  at  a  feature 

Assess¬ 

ment 

o 

o 

WARSIM 

Data 

Type 

Entity  Name:  MAT_ITEM_CONSUMPTION 

CO 

o 

z 

Q 

_l 

X 

Attribute 

(A 

i/i 

(0 
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Table  F-17.  Mapping  CONSUMABLES  to  WARSIM 
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Table  F-18.  Mapping  EQUIP_TYPE  to  WARSIM 
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Table  F-19.  Mapping  SENSOR_TYPE  to  WARSIM 
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14.  ABSTRACT 

This  paper  presents  an  assessment  of  data  model/object  model  alignment  between  C4I  and  M&S  models.  In  the  C4I 
domain,  two  models  are  examined:  NATO’s  Land  Command  and  Control  Information  Exchange  Data  Model 
(LC2IEDM),  and  the  Joint  Common  Database  (JCDB)  Data  Model  (JDM).  In  the  M&S  domain,  the  model  is  from 
WARSIM,  the  Land  Component  of  the  Joint  Simulation  System  (JSIMS).  The  paper  shows  that,  although  there  is 
substantial  overlap  in  the  data  modeled  by  WARSIM  and  the  C4I  models,  some  data  areas  have  significant  problems  in 
mutual  coverage  and  compatibility  The  LC2IEDM  and  JDM  do  not  adequately  capture  some  of  the  dynamic  data  that  is 
necessary  in  simulation,  and  the  WARSIM  model  cannot  fully  describe  the  real  world  as  the  LC2IEDM  and  JCDB  expect. 
The  paper  addresses  data  alignment  between  WARSIM  and  the  LC2IEDM,  making  specific  recommendations  for 
changes  to  them  that  would  improve  their  interoperability. 
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